jml's notebook
Ensuring quality enables throughput
Often in software development, caring about the quality of the things we are building is seen as an extra cost that must be justified on the potential benefits, such as improved user experience or lower maintenance.
From the engineering perspective, quality is frequently seen as an essential moral good. Sometimes we forget that the quality of the product and the quality of the code are two different things, although one influences the other.
Both of these are good, but I think they miss something important. Insisting on building high quality software is an effective means of /attention management/.
If a component or feature is low quality, then it is a source of distractions. Perhaps it causes bugs that need to be fixed. Perhaps its poor interface makes other work needlessly difficult. You can think of these bugs or difficulties as interruptions, like a child coming into the room to ask you to reach for something down from a shelf.
Whether or not you actually do anything about these interruptions is irrelevant, because deciding /not/ to do something still takes time and energy. In a corporate context, it can take quite a lot of time and energy, as people will keep wanting to talk about it.
Another way of saying this is that low quality software is unfinished. It still makes demands on your time and attention.
As you keep building buggy features, dodgy components and awkward interfaces, you add more and more sources of distractions. Your environment drowns in noise.
However, if you actually finish your work, if you produce high quality features and components, then you are free to move on to the next thing. Then, instead of you doing work for those components, they do work for you. Because they are trustworthy, you can build on them.
Thus, building quality in actually enables speed of execution. It increases cost, but it also disproportionately raises the ceiling on the adjacent possible.