As I'm looking for a new job as a web developer, I'm looking at my reasons for leaving a wonderful company with a senior position to join another project. Let me tell you how the extra cost of quality made me lose my footing.

Companies naturally evolves from feature-oriented to quality-oriented

Software development is successful when the customer is satisfied and the company has sufficient revenue. There is a break in the life of the project: it's when there are enough customers to provide support services. In this case, the company chooses to focus on the quality of the most lucrative functions, and to redistribute expenses towards building customer loyalty. Congratulations, you're part of a sustainable company!

Here is an exhaustive list of practices to focus on quality:

• The basics: hire skilled employees, use ticketing & versionning flow, follow standard practices of your choosen tools.
• Contribute for continuous improvment (plan, try, measure, standardize).
• Add or switch for some better tools (read benchmarks).
• Add automated tests (unit tests, end-to-end tests, non-regression testing).
• Add automated workers (linters, code-analysers, automated code-reviewers).
• Delegate checks to machines (CI/CD).
• Forcing more manual tests or hire manual-testers.
• Dedicated teams (release, cybersecurity, compliance), audits, formations.
• Run AI in your project.

There's a big difference in quality rules between a business-to-business software with 150 users and thousands of functions, and a retail application for 100k simultaneous customers and only one purchase function.

Your company will add more quality rules, sometimes after a critical problem, sometimes in anticipation of problems. The more rules you add, the more expensive quality becomes. You can then calculate the cost to obtain quality (COQ):

Cost of bad code =
  Human time for resolving issues + Bad reputation

Cost of good code =
  Human time for quality + Cost of dedicated machines

Cost to obtain quality =
  Cost of bad code + Cost of good code

Why the hell any company would choose bad-quality?

They don't! No company would allow crappy code with security issues. No, they wouldn't. But you have to recognize that quality is clearly not the priority when you have no customer, no budget and the concept is still evolving.

You then need to hire people who are quick to develop a saleable product, you need to focus on highly anticipated features that will set you apart from the competition or improve your public image.

Force developer have good practices

A company that is making progress and maintaining good relations with its customers will evolve its profile to match those customers. The company will also evolve the profile of its developers in this direction, by imposing rules that are of interest. Developers take on board the new rules, change their habits and acquire reflexes for their working day.

Customers expectations -> developers new reflexes

But don't lock the development

However, companies can become over-costly on quality and forget to develop new products. As a result, marketing-commercial-product plans dilate and new products are delayed.

A company with quality overruns can be identified by a decrease in technical work time, a lengthening plan, rules that prevent novelty, difficulty with change, long processes, interminable meetings with little added value.

A good practice is following continuous improvement.

To get started, define your actual status:

• by listing what matter for current customers,
• by listing opportunities,
• by measuring time to market,
• by measuring quality.

The next steps are to plan numerous improvements, select and implement a few at a time, then check that they're working for you. An improvement could be adding good-practices or reducing processus.

Example of quality surcharge on web-development

It's time to share my personal experience with you. Several companies have followed this path and ended up, in spite of myself, being unable to develop new functions in their applications, as a result of an accumulation of rules, which often took them out of Agile good practice, in order to have over-control, or to protect themselves from a non-existent risk, or finally because the company was no more expecting new features.

The company I work for started with a CI/CD and unit tests on main features. Now we changed for a custom CI/CD with AWS, running unit tests for 75% coverage, running non-regression tests for 40% user journeys, with 20% employees dedicated for QA, 1/3 week for release production with 90% employees of the company (product, quality, developers, infra). The cost of quality is actually 80% of the budget (employees and AWS CI/CD) and there is no more time for new feature here. Actually, the customers are satisfied by product, but are awaiting for some expected features, and quality issues are from product (no more technical issues).

It's time to change company mind and find a better fit for customer expectations.

Conclusion

In order to control the cost of obtaining quality, we need to ensure customer loyalty and develop our customer base, and adapt quality, costs and time to market. It's not uncommon to fall into the trap of over-quality. In IT, however, you have to keep inventing new things to ensure the longevity of your business, and controlled risk-taking remains the best strategy.