Structure Eats Behavior for Breakfast
Prioritizing software defects
Peter Drucker said that in business, “culture eats strategy for breakfast.” In software development, structure eats behavior for breakfast. Over time, structural flaws overwhelm behavioral strengths, and structural strengths cure behavioral flaws. By “behavior,” I mean “what the software does,” and by “structure,” I mean “how the code is shaped.”
Two kinds of defects
We can divide software defects into two broad categories: on one hand are behavioral defects — what we often call “bugs.” On the other hand are structural defects. Bugs are apparent to users of the software, but structural defects are usually invisible to everyone but the programmers. Structural defects make the software more difficult to change.
Crucially, the changes impeded by bad structure include changes to improve structure! Structural quality is therefore caught in a reinforcing feedback loop:
The good news is, this loop, like all reinforcing loops, works both ways. Improvements to structural quality make further improvements easier. They also make it easier to improve behavioral quality, i.e. to fix bugs or add features.
A thought experiment
Imagine two software systems, A and B. They have the same set of features, but:
System A has a clear, simple structure that’s an excellent fit for its purpose. Unfortunately, there are logical errors in the code that cause it to produce incorrect results.
System B has no known bugs, and always produces correct results. Unfortunately, it has an overcomplicated structure that obscures the mechanism by which it produces those results.
Ignore, for now, whether these systems could or would ever be built as described. The question is, which one would you rather own?
If you aren’t ever going to change the software, you’ll answer “System B.” But of course, that’s silly. Software always needs to change.1 And it will be much easier to fix the bugs in System A than it will be to fix the structure of System B to the point where you can develop new features safely. System A is almost certainly the better long-term choice.
How it goes in reality
In the real world, of course, we aren’t given a choice between System A and System B. Structure and behavior evolve together, and bugs tend to crop up when and where the structure gets confusing. We tend to find that systems either have both good structure and good behavior, or bad structure and bad behavior.
What I’d like you to take away from this post, then, is this: efforts to fix bugs will be largely vain in the face of bad structure. When you find yourself facing a slew of bug reports, don’t focus on squashing the individual bugs. Try to understand the code first. In order to understand it, you may have to start improving the structure. Get the structural problems under control; then the bugs will pack up and leave on their own.
Well, almost always. There is one exception: cat is perfect and will never need to change. If your program isn’t cat, though, it’s going to change.