My boss used an analogy today, which struck me as quite accurate for the position we’re currently in. We’re moving at a fairly rapid pace, quick releases, and plenty of improvements / changes. Along with this, there is new business, new ideas, and new potential sources of revenue that we’re working on.
Assuming that the speed of the vehicle is constant, and the winding is fairly unknown, how do you best prevent hitting the walls? This part of the analogy is talking about software quality. While no one is perfect, reducing the amount of churn on bugs and enhancements allows for time better spent on other things, be it additional bugs, new enhancements, or time to re-design the credit card processing module to be more efficient.
In keeping with the analogy, I tried to think of various methods to implement, which prevent hitting the wall. The first, posed by my direct superior was to ‘increase the accuracy of the driver’. This is the ideal solution, all things the same. But, what other factors contribute?
Part 1 – Size of the car
Reducing the size of the car will generally improve the accuracy of the car. Now, with this analogy, I’m thinking in terms of relative extremes, and I won’t delve into the nit-picks of which 2-door sport coup is the best for suspension. So, consider 2 vehicles. 1 – a smaller 4-door sedan, low-profile, but consistent acceleration / braking. 2 – an eighteen wheeler – hauls, but reaction time is limited, and said reactions are greatly exaggerated.
A smaller car here represents a focused small unit of developers. These developers are typically the medium-high to high performers, able to deliver on quality in terms of fixing an issue, and in terms of overall design and architecture. They work closely together in a nice cohesive environment, with limited distractions. This allows for quick reactions to change, more rapid context-switches between projects, and good performance. But, the amount of total ‘fixing’ they can do is limited (they’re in a sedan, for petes sake!).
A big rig here represents a bigger team, with a wider range of skillsets. You have the higher performers, but also the medium-lows (no lows here, that’s just not pleasant). Likewise, the medium-lows can deliver, and the solutions work, but they may not be fully thought out, they may not consider some design flaws in their solution which could impact maintainability down the line, but they _can_ deliver a solution. This team moves along quickly, making a lot of changes, but with unexpected turns ahead, the reactions and turns cause turmoil and disruption. But, at the end of the day, there is quite a bit of things being fixed, the worry though is, is it being _really_ fixed?
Is the amount of items being fixed the goal? Or, can you afford to delay a while, but in the end deliver a more solid product? Over time, the lines will converge, and the products will more than likely appear similar, and operate fine, but did your reputation suffer along the way? Are customers willing to wait, if they know the problem will be resolved to their complete satisfaction? Or, do customers accept a partial solution, and potential headaches, but know that eventually the problem will be fully resolved?