One frustrating evening years ago, when I was a professional scientist and a self-taught programmer, I blurted, “Programming takes longer when I’m in a hurry than it does when I’m taking my time!”
Whoever said “Fast, Cheap, or Good—pick two!” started a dangerous lie. Unless it’s extremely simple software, to be used by its creator, once, and then deleted from the computer, improving quality makes the software less costly, not more.
OK, this isn’t true if you’re writing software where people could die if there’s a single bug (mistake) in it. That level of quality costs extra.
But for typical business software, there’s a sweet spot of quality, and most organizations aren’t there. Unless you have intentional quality measures in place, you can probably double your productivity by doing a little extra work of the proper sort at the right steps in the process.
So, why are effective quality practices not universal?
- To uninformed outsiders, everything but typing looks like Extra Work. Budgets with tasks (as opposed to features) as line items invite cutting quality measures to save time or money (but it doesn’t work in the end). Feature-based budgets are better because they drive conversations about feature value and scope when “cutting to fit.” But if your organization has separate groups that do quality-related tasks, task-based budgets are hard to avoid. Many big shops are organized this way.
- The most cost-effective quality measure, formal Inspection, isn’t as fun as programming. Lesser forms of requirements, design, and code review, while not as anal-retentive as Inspection, are less effective and still not as fun as programming. “The only problem we have around here is not enough meetings,” said no programmer, ever. Startups begin with just programmers (and maybe UI designers) and it’s easy to establish an inefficient code-and-fix culture and lay down a foundation of low-quality code that makes it hard for the business to pivot or scale up.
The first “quality measure” most firms introduce is Testing, in order to keep External Quality at an acceptable level. (External Quality is essentially, “does it work?”) The problem is that testing can only detect mistakes, not prevent or fix them, and then it can only detect certain kinds of mistake. Software can have high External Quality but still be made of Magic Spaghetti—poor Internal Quality.
Improving Internal Quality is where the payoff really happens. The reason why the quality curve looks the way it does is that tracking down mistakes in software is the most time-consuming form of Extra Work there is. It’s also hard to predict. Quality measures other than manual post-coding testing pay off because they detect mistakes relatively soon after they’re made, when they’re still easy to find.
Although I believe it’s easier for most teams to create high-quality software using an Agile method (I’m assuming this means automated testing, one of the Load-Bearing Walls of Agile), quality isn’t the main reason I prefer Agile. Regardless of methodology, introducing the right quality measures is a sure win.
Waterfall shops tend to use more formal requirements, design and code reviews, while Agile shops tend to use refactoring, supported by automated testing. Coding standards, especially naming conventions, are a good idea anywhere, provided they don’t trigger a religious war. Most languages have one or more de facto standards. Pick one and use it. Pair programming is the Agile form of code review. It catches a lot of mistakes but drives cost accountants crazy, unless they believe the quality graph. The most common review mistakes are reviewing too late and reviewing too much at once.
Another term for poor Internal Quality is Technical Debt. Like financial debt, it bears “interest,” in the form of extra time spent changing, enhancing, repairing, and upgrading a system that’s full of Magic Spaghetti and therefore hard to understand and change without making another mistake.
So whenever I have to help a firm Make Software Better, I first help them get a grip on their commitments. That frees up some time for them to introduce some quality measures. Those take time to gain traction. The longer the cycle time (time from gleam in the eye to feature in use), the longer it takes for the low-quality work in progress to clear the development pipeline and—gasp!—enter production, where it will continue to drive higher-than-necessary costs until remediated.