According to the Standish Chaos report, 31% of IT projects are cancelled before they arecompleted, and only 16% are completed on time and budget.

There are many reasons why software projects fail, but today we’re going to drill down into software quality. We will review both agency and individual software developer traits that may hinder your business proceedings, and some of the things to look out for.

What makes some software ‘good’ and some ‘bad’?  If your software isn’t doing what you want it to do, why is that and what can you do to fix it?  What are the three most important things your software team needs to be doing to ensure you get good results?

Let’s start with one of the biggest challenges of all, how do you know if a software developer is going to be any good?

A sea of mediocrity

It’s easy to be an okay developer, but hard to be a great one.

If you want to be an accountant, or a lawyer, or an architect, or a doctor or an airline pilot you have to get the right qualifications.  There’s a recognised process that guarantees a level of understanding. If you want to be a software developer you can just watch a few Youtube videos.

It’s not even as if there is just one type of software developer.  People specialise.  Some are great at creating user interfaces that are smooth, attractive and easy to use.  Others are better at writing the complex stuff that goes on behind the scenes.  Some prefer to get stuck into data and others want to do the really low level stuff.

According to research from Microsoft and the University of Washington, great software developers can be judged in four dimensions:

1. Personal characteristics (like being open minded, always seeking to improve and showing passion of the job)
2. Decision Making (can handle complexity.  Sees the forest and the trees)
3. Team (Is honest, creates a safe space and shares)
4. Technical Skill (Combines elegance and creativity, anticipates and is attentive to details)

We’ll come back to those in more detail, but first, let’s look at some of the unhelpful developer attributes you’re likely to encounter if you’re trying to get software developed:

Unhelpful Agency Behaviours

Agencies can be a very effective way of delivering a product, but they can come with their drawbacks- and the array of agencies available can be overwhelming, each with a different overall specialisation and different internal specialisations and structures. The most important things to consider when choosing an agency are their track record, skill level, and work culture. I’ve pulled together a list for you of things that you may want to be aware of that an agency may do, which could hinder your project.

1. Software agencies pretend they are very cheap.  They bid low on jobs knowing that once you’ve started working with them it will take a lot for you to switch to someone else.
2. You find you’re constantly being told that something you want isn’t in the spec, so you have to pay extra for it. This rate may be higher than what you had originally been offered.
3. Bugs get fixed once, then come back again, and again, and again. In the meantime, you’re being charged for the cleanup. You can absolutely expect some bugs in development, but once a bug is fixed, it shouldn’t be coming back so often.
4. Software gets delivered to you and it doesn’t do what you asked for it to do. Either it’s not quite in spec, has too many additional features, or doesn’t work consistently. In the end, you have to go back and pay for it to be fixed.
5. When you agree that a change is needed, and it’s within spec, it turns out to be really expensive to make the change.

All of these problems are common, but there are some ways around it:

1. Know the true cost of the build. This can be extremely difficult to pinpoint, but getting plenty of different bids can help you to estimate. The cheapest offer available is often going to be far more expensive down the road.
2. Know how many other projects the agency has going on at the same time. This can give you a sense for how much focus is going to be on your project, and you are less likely to have specifications slip through the cracks. Specs can change and that’s understandable, but the rate shouldn’t be ridiculously high.
3. Know how much changes might cost before settling in with an agency.

Choosing an agency is quite a commitment, so you deserve all the information you can gather on it before you make a decision.

Some questions you can ask are:

1. (for an agency) What is your ratio of full-stack to specialised developers?
2. What do you specialise in?

The Rookie vs. The Professional

Because the barrier for calling yourself a software developer is so low, there is an enormous range of quality within that title. Some software developers are extremely seasoned and are unlikely to fall into the traps we discussed earlier- some have years of experience and have firmly settled in to one of those ‘types’. However, if you know what a rookie developer looks like, it can make it easier for you to identify one with much more experience.

An inexperienced developer is likely to be much more motivated by the latest fashions in development, or seems to take the project in tangential directions (like a magpie). If they are adding things on that you didn’t ask for initially, don’t be swept up in this. You have finite resources and new additions should align with your business plan.

The experienced, professional developer understands development as a means to an end. That’s not to say they don’t enjoy the process, but you need a developer who is more interested in providing you with the product you asked for rather than tinkering.

Professional developers know that the process isn’t about “moving fast and breaking things”. They know the software they build has a lifetime, and won’t be the best solution forever.

The amateur assumes what they make will go global, but the likelihood of them writing the ‘next facebook’ is unlikely. Tech decisions must align with business strategy. in the enterprise software world, there are many stakeholders, and everyone involved must understand.

A professional developer is like a craftsperson

A good software developer is like a craftsperson. They apply their skills, know how and when to use the right tools, take pride in their work and create results you trust.

How can you tell?

Experience. How long have they been a software developer?  What projects have they worked on?  What languages do they know and have they worked in detail or just scratched the surface.  A good developer will learn a new language quickly but they will also know that they are not experts straight away.

Domain.  Do they have any experience in the specific industry you want them to work in?  Do they know about the most important topics, the hidden traps, do they network with other people in that industry?

Enterprise Grade.  Have they build software which is used by serious organisations in real world settings?

Teamwork. Have they worked as part of a team?  Do they understand the value and importance of other roles such as Designers, Testers and Project Managers?

Do they know how to use the right tools for the job?  Do they understand the principles for things like Source Control, Dev Ops.  Do they know about using design patterns, and choosing the right one? 

Even really good developers make mistakes sometimes. We all do. I’m not suggesting that a development process is entirely free from error. What I do want to say is that bearing these things in mind can save you a lot of money in the long run, and result in a better final product.

One of the first things you’re looking for from a finished development project is that it holds up in these three areas: Security, Reliability, and Maintenance. The best software is secure, reliable, and maintainable. All of these sit on a foundation of simplicity. Complicated software is complicated to fix.

Secure software is software that is unlikely to be broken into, attacked, have data stolen from it, be brought down by malicious 3rd parties etc. There are plenty of bad actors who would be happy to have information from you, even for the most innocuous things. Some people break things for fun. It’s better to keep security at the front of your mind, because it’s key for consumer trust, no matter what you are developing.

Reliable software is software that is unlikely to crash, have bugs, and will do what you want it to do in a simple way. You can reasonably expect that the software you paid for holds up consistently. A first time user, when coming across a bug or a crash, is very difficult to win back. Many just won’t give the software a second chance. Having software that is robust from the get-go is extremely important to getting funding, bringing consumers on-board, and for the health of your overall business. Not to mention, it is what you are paying for! Crashes happen, but they shouldn’t be happening frequently.

Maintainable software is software that is easy to change and, should the above two things happen, is easy to fix. If something does go wrong, the code should be set up in such a way that response is efficient and timely.

Simple software is also cost-effective, because complicated code takes a long time to write and even longer to identify bugs or changes that need to be made.

We spoke about this briefly with the ‘hero’ subcategory earlier in this conversation. If you bring another person on to the team and they have to spend forever figuring out how it works, or if the developer brags about how he or she are the only ones who can understand the code, it is probably overcomplicated and delicate and not the robust code you need. 

• You should be able to bring new people on to the team and have them know what to do straight away. If there are errors or a breakdown happens, it should be relatively simple for them to go looking for the issue.
• Code which is well structured and developed in such a way as it is easy to hand over is higher quality than complicated code. It always comes back around to simplicity.

You shouldn’t need a ‘hero’!

A high number of tests does not guarantee a great product

This is something that I see relatively often. Not only should you know how your code is being built, but you should also be aware of how it’s being tested. 

Some developers test their own code. This is very rarely the most effective way. It is extremely difficult to test your own logic, so having someone other than the developer who is specialised in testing code is important.

A higher quantity of tests does not make for a better resting regimen. Sometimes you’ll hear boasts about the number of tests executed, but this really doesn’t mean anything substantial. If you check the same wire 10 times but neglect the other 9, you’ve run 10 tests but not actually tested all of the wires. In this way, there is no correlation between the number of tests executed and the testing quality. Framework code, for instance, has components that have been thoroughly tested by companies like Microsoft. The tests that are run should challenge the developer, not just validate them.

Avoiding the house-of-cards effect

This is something that is absolutely worth knowing when you go to development with your software idea, and you’re working with a developer. We’ve discussed the traits that can be less helpful to your project, some positive attributes to look for, and the same for the code itself. The ‘house of cards’ effect is when the code is overly reliant on one single component or feature that can go wrong. 
 

• If each and every component relies on every other component to work, there is a higher likelihood that the entire structure will fail. The components should function independently of each other.
• This is more of an indication of the quality of the software itself, but a good software developer will understand this
• and work in such a way that the entire product will not stop working if only one part stops working.

You may be aware of the most famous example of this, the L-pad example

L-pad is a node.js component padded test on the left hand side to essentially right align it, which was practical for a lot of uses. It then made its way into a node module which others were able to access and use. L-pad over time was used to build many things, until it was used tens of thousands of times per day, and was even part of things like the Bank of America website. The individual who wrote it fell out with the group hosting the node package and it was removed from the repository, which resulted in everything that was using it to break. This created absolute chaos in front end development.

People just weren’t aware that their software was using L-pad, because that was ’just the way it was done’.

The way your team can avoid this is by knowing what your ‘reliances’ are. If you rely heavily on one particular component for your software build, it’s good to know who built it, whether it’s being maintained, and how secure it is. If that particular component fails, workarounds should be available. This will keep your software robust, so that your project doesn’t crash further down the line.

Conclusion

We’ve discussed the traits to avoid when choosing development partners, as well as some positive attributes to look for. You should always be able to find out the mindset and career background of the developers working on your project, and know what you’re looking for when you speak to them.

Find out the processes they follow through development, and which things they view as most important, such as auditing and successful release. 

Know the processes they follow throughout development, and which processes are the most important. 

Know the testing procedure for your software.

These are some of the ways you can make sure the development team you hire is best suited to the task, and that the software products you receive will be cost effective.