So, I was watching one of those Trauma in the ER shows, and one phrase kept coming up: “We need to stabilize the patient before we can do anything else.” It makes me glad that some of us software developers didn’t go into medicine. If we treated patients the way we treat our code, well, let’s just say lawyers would be very happy. Think about it. We, as an industry, as a general pattern, are usually heads-down coding. That giant heap of defects? That’s for later, when we are “done”. However, continuing to move ahead without constantly stabilizing the system leads to some very bad consequences down the line.
I get it. We developers get busy. Code this – check. Build that – check. Fix that defect – “Nah, I got “real work” to do. I’ll get to that later.” Problem is, later usually comes too close to the release deadline. Way too close to deal with all the built-up backlog of dozens, hundreds or even thousands of defects.
It’s bad enough that each defect is non-value-added rework that takes us away from productive work. It’s worse that each one takes what seems like forever to resolve. But worst of all, that amount of accumulation sets us up for risk in delivery. In Lean, this would be identified as one form of WIP – Work in Process – or what we instead like to call, “Work in Progress”. WIP is whatever needs to be finished to realize value in the customer’s eyes. It could be incomplete features that we’re working on, but it could also be open defects.
The answer to combat a mountain of WIP is as fundamental as it is simple: STOP.
Stop letting defects accumulate. In Lean thinking, this is called implementing a ‘WIP Cap’. How do you do that? Easy. Pick a number, any number, preferably less than or equal to the number of fingers on your hands. When the team reaches that number of defects, stop working on features. Stop working on code. And I don’t mean just you. I mean ALL of you – the entire team, Q/A included. Start analyzing and fixing the defects and burn those down before continuing. How far do you burn down? As far as you can, preferably to 0. The WIP Cap concept is fundamental and can help transform your organization.
Granted, implementing a WIP Cap isn’t easy, especially when we’re working against a deadline. But without it you’re going to keep developing with unstable code. And that instability will create new defects that interact with pre-existing ones. Worse, tackling a horde of these defects, piled on top of each-other, only leads to more regression.
With one of our clients, this phenomenon led to a find-fix rate of sixteen hours per logged defect, on average. Worse, due to the brittle nature of the code, they experienced a domino effect: Fixing one defect created one or more new ones. The more the team rushed to meet the deadline with an unstable codebase, the more delays they experienced. The first change they made for the next release was to implement the WIP Cap and it paid off.
So how would you implement a WIP Cap? Well, do your job and build good software. When you see a defect, instead of throwing it on the pile, fix it. When your Q/A or any other team member finds a defect, fix it. If it can’t be fixed right then, log it and fix it as soon as possible. Sometime before or when the WIP Cap is hit, STOP. Triage. Prioritize. Organize. And fix. Stabilize the patient before moving on. As much as it hurts then, you will save more time off the backend than you realize. Aiming for high quality will actually help pull in the delivery date, and, like parfait, everyone likes that.
