It can be a struggle to answer this age-old question. It’s arguable that some very successful products weren’t originally concerned about quality and have become massive hits (see Facebook). And if it worked for them, then why can’t it work for everyone?

In a world where products must be shipped as quickly as possible else be lapped by the competition, it’s difficult to prioritize quality over feature work. It’s been proven by others that focusing on feature development only can work for a time but in general, steps need to be taken to improve quality once a product reaches a critical mass in usage. Otherwise the stability of the entire product is at risk.

This argument alone doesn’t make quality important. What does make code quality important is its measurable benefits to the business.

Business Outcomes of Quality Code

Quality results in an increase in customer happiness when using the product. The customer won’t ever see the code but they will know if it works well. Crashes and unexpected errors are the most common signs of badly written software. A customer will notice crashes. A customer will notice errors. Actively taking steps to ensure that your software is stable will make your customers happier. And a happy customer means more repeat sales.

Quality provides an increase in confidence when selling the product. You want your sales teams to put their best foot forward with new customers. There’s no better way to help them than to hand them a reliable build that they can confidently demo to anyone.

Quality allows faster delivery of features through process improvements and automation. Putting best practices in place is the only way to ensure that you can innovate quickly with the confidence to know that the features are rock-solid.

Quality saves time on maintenance. You want developers working on new features, not maintaining existing ones. Not to mention that bugs give your clients leverage to lower the sale price or switch to a competitor.

The development team will take ownership of the code-base. Developers want to build reliable, scalable and maintainable code. Nobody wants to work on spaghetti code. Giving them the support they need to build it right the first time will increase their engagement level.

Does everyone need the same level of quality?

Nope. Every piece of software will have different needs in terms of quality. Here are a few examples to illustrate:

• NASA needs every mission-critical system to have 100% reliablity plus a redudancy in case there are non-foreseeable failures that occur. Stability is critical to any code that they write.
• Facebook has traffic levels beyond what most other companies dream of. This makes scalability a key element for them.
• Stock traders on Wall Street need their software to run quickly so that they don’t miss an opportunity due to sluggish response times. Performance is of the essence.

Every team must define its quality goals. No article on the web can tell you which aspects of quality are most relevant to your project so go through them as a team and put an action plan in place.

Don’t Go Overboard Building Quality

There is a balance to be had between speed of delivery and overall quality of the application being delivered.

Developers, by their nature, want to make software as bullet-proof as possible. It’s very tempting to try to protect against almost every eventuality. Using the 80/20 rule to decide what cases to cover will likely provide the best value to the business.

Code quality does not ensure the success of a product but neither does bad code. Building a product is a complex process involving everyone in an organization. Put your product on the right path by ensuring that quality is at the core of everything you do.