What's Bug Tax
The bug tax is a form of friction that increases with the pace of development. For each new feature added, your software gains a number of new bugs. Minimizing the time your team spends bug chasing results in greater productivity, and coincidentally more time to add new features (which introduces more bugs). Good job, you just made yourself more work.
There is a well known question software developers face. Is additional utility worth the complexity and cost in debugging or redesigning existing structure? It sits at the forefront of every serious designer's mind, and when increased functionality is favored too much we call it feature creep. This concept transcends software design and is evident in just about any project design (my blog layout is a perfect example of feature creep with information overload).
These bugs are introduced by state complexity and the limitations of individual developers to hold entire applications, all dependent libraries, and there interactions in mind simultaneously. On my best day I can keep two large applications and many of their nuances in mind, add a third and everything falls apart. In fact if I'm working on just one, I'm much more productive. Let's review state complexity briefly.
Exponential Network Interaction Growth
Say I have one type of data structure and two possible states (on or off). The state complexity of a single structure is nice and simple (size 2). Scaling that structure is a matter of geometric growth (wiki reference). Add N more instances of that structure and I've added two to the N possible states to be concerned with (this is how numbers are described with binary data). Now introduce one additional interaction or state and expand the number of total states many fold (an additional base state causes system expansion to 3 to the Nth power unique states).
Why it's not that bad
In practice this is not always as terribly complicated as it sounds. If you have high confidence in your design's current functionality, adding linear increases to complexity doesn't "break the bank" unless you are already at a resource ceiling. Resource limitations of bandwidth, acceptable delay, computer memory, and the most important developer neural ram ;). You can buy more hardware, but each developer's mind is memory limited. New team additions require familiarization with the project, and this is an ongoing and predictable cost.
If you are working with solid software developers, they'll have intense practical heuristics which help pair down massive complexity to manageable levels. If your team rigorously tests software, the bug is almost certainly in the latest software addition. But it's also possible that the latest features reveal existing defects or design limitations.
When is an Additional Feature Worth the Bug Tax?
According to one of my favorite coding authors, who has extraordinary enthusiasm for startups, Paul Graham suggests (in Wealth) that the best path for a startup project is the steepest ascent (which reminds me of conjugate gradients).
Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him.
Now it's time I get back to debugging at Victus Media. We introduced some bugs while fixing others last night.
Related Links: