Two sides of the same coin
In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions. It is often described as the ‘fitness for purpose’ of a piece of software.
Quality and speed are usually defined as opposite things in software development. If you have quality in your code you will ship fewer features to production and the opposite, if you have a great speed in your team you will have low quality.
In my experience this is not true, quality and speed are just values of the same thing, the pace.
For example Usain Bolt is able to run faster than anyone else, but he runs in a way to avoid injuries. We could say that he runs with quality. I don’t think it’s possible to be so fast without applying quality and being so many years in the top.
Let’s go back to software if you have been working in a company with a legacy product you know what was the consequence of the poor quality. The company at the end will decide to rewrite all that code with a higher level or quality. Do you think is there anything else more expensive than rewriting all the code?.
Why a project one year-old is difficult to update comparing it to a green field project, why we need more time there than in a new one. This is not because of people, we are the same in the team. The real problem is the quality of the code, basically the kind of job we did to maintain the quality in a good level or not.
If we have too much tech debt we will spend more time fixing bugs, trying to coordinate people with meetings to avoid known problems. At the end is the poor quality of our code the cause of our low performance?
Cost of a Feature
In this video ☕ J. B. Rainsberger defines the cost of a feature:
The cost of a feature is a function of both essential and accidental complication:
cost of feature = f(g(e), h(a))
Essential complication or g(e): How hard a problem is on its own. For example, implementing tax handling is hard, because the tax code is complex in itself.
Accidental complication or h(a): The complication that creeps into to the work because “we suck at our jobs”. Or more diplomatically, the complication that comes from our organizational structures (how long does it take to get the approval for a new test environment?) and from how programs are written (no one is perfect, therefore some things need to be changed to accommodate the new functionality).
Accidental complication usually dominates the cost of features, it includes:
The codebase, how difficult is to change it.
Our path to production. The steps to take after developing the feature to deploy it to production.
Bureaucracy in general.
Then more quality means less accidental complication so the cost of a new feature will be lowed. Why people usually think that more quality means lower speed?. The problem is how we add quality to our product.
The truth is in the process (don’t block)
The way normally companies have introduced quality in their codebase was adding blocking steps (waiting for approvals). For example:
Automatic tests are a technique to increase maintainability of our codebase. But if the team is not writing automatic tests and is waiting for QA to pass those tests before deploying we get more accidental complication.
Code reviews are a known good technique to increase quality in our code base, but if code reviews are lasting days then it can convert themselves in accidental complication.
If dev team members must wait for decisions of architects outside the team then you will have more accidental complication.
But we can add quality without adding more accidental complication. For example:
Maximizing the use of pair programming as an alternative to code reviews
TDD instead of doing tests after
Autonomy for dev teams
So we need to use processes that include quality as a first class citizen.