When developing software, I want to build applications quickly. In my sometimes painful experience, low quality work gets in the way of this goal. There are a lot of problems with poor code quality, but I want to focus today on how code quality is directly tied to the amount of work in progress. Low quality code leads to large work in progress which in turn causes slow and uncertain delivery time of new features.

I tend to think of low quality code as any code that leads to defects that require rework, i.e. bugs. There is an inherent challenge in this definition because it’s hard to know what will cause a bug until the bug shows up. But from experience, I know there tend to be more bugs when I write the code quickly, working alone, and without writing or running tests. There are a lot of different ways to write bad code, but those are some of the common ways I do it : ).

The low quality code really starts to be a problem when I “finish” some features and move on to developing new features. The poorly written code is not really done. Most likely it still needs some rework to really function the way it is intended. So in reality, I have more work on my plate than I can handle efficiently. Major bugs crop up more frequently interrupting me and causing the time to finish any feature to increase.

It turns out that there is no way to get around the fact that more work in progress leads to longer delivery time; it’s Little’s Law. If you have a system with items coming in that have to wait in a queue before they can exit the system, then the number of items in the queue is directly proportional to how long, on average, that it takes to process a single item. This makes sense. Long lines mean long wait times. But when it comes to planning work, it is easy to think that I can get everything done at once.

To achieve a quicker cycle time, I need to insist on high quality work to avoid the pile of work in progress from unexpected bugs. A faster feedback cycle is super beneficial. With complex products each bit of work that we complete gives us new insight into the system, and ideally we would like to incorporate those learnings into deciding what to do next. The only way we can do that effectively is to have short delivery time of features.

This is my understanding of the connection between work in progress and delivery time related to my experience, but I learned about this connection first in Kanban: Successful Evolutionary Change for your Technology Business by David J Anderson and more recently in Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin.

I hope to write upcoming posts about specific things that I have found helpful in my efforts to improve the quality of my code.