Two maxims for practical software development

My previous software development job may not have been good, but my boss there was. Eric was thoroughly the practical sort who didn't care much to philosophize about the what ifs or shoulds of his circumstances but instead gave his attention to making good software with what he had. It shouldn't be too surprising that with my theoretical leanings I had my frustrations with some of his decisions at the time, but in the nearly four years since, whatever disagreements we had have been buried, and meanwhile I've retained some of his practical insights, As a result I've become a more balanced developer, though of course I'm as inclined as ever to discuss the what ifs and shoulds of my circumstances.

In the ensuing years since that job, I've elevated two maxims of Eric's to a sort of gospel status, and in today's blog post I'll share those ideas.

Bugs that go away mysteriously have a way of returning mysteriously.

I get the most mileage out of this in software, but it's also applicable in other disciplines, such as bicycle maintenance and interpersonal relationships. Stated another way: don't fix effects; fix the cause.

Here's an example. Recently at my current job I was doing some embedded development and ran into some timing issues whereby the unit's LED display was showing incomplete or garbled messages. I could fix the problem, by which I mean that I could make the display correct, by inserting a slight delay into the code. I did so and mentally filed a note that I had a system that, according to Eric, chapter 1, was hiding a bug. Sure enough it took only a few days of continuing work on the system before my existing delay proved insufficient and the truncated-message symptom reemerged due to some seemingly unrelated code changes. I decided to figure out the display problem's cause, and after some time determined that I had misinterpreted the hardware documentation. I changed a register value assignment (according to my new interpretation of the documentation), and the display worked correctly without the original delay hack. Bugs that go away for known reasons have a way of returning rarely.

People will be quick to forget that you were late to release but will be slow to forget that your product was initially buggy.

Professional software development is often an exercise in blundering. It's well known, at least within our industry, that software is hard to make; it's terrifically complex stuff, its development is notorious for missing deadlines and exceeding budgets, and a lot of software released into the wild just plain sucks. Despite this, releasing on time a product of poor workmanship is not hard and won't earn you much distinction as a developer. What is hard and will earn you distinction is releasing something that does what it needs to do and does it well. This makes sense: the three months you're late with a project may feel like an eternity while you're in them, but they'll pass soon enough and if you end up releasing software that can be trusted then its users will usually be satisfied and those three months won't seem as big a deal after the fact. But if you release buggy software then even if it's on time and even if you've successfully fixed all the problems (and fixing released software is usually harder than fixing unreleased software) then the software's users will generally hold a vague distrust towards the system for a long time (if not forever). Once broken, never trusted.

I have a theory about the phenomenon to rush out a software release of poor quality, and it's to assign a lot of the blame on the college experience. In college the first priority of any assignment (for most students) is the deadline and secondary is the quality of the job. After all, for papers and tests the student generally must be there on time or else a lot of credit is irrevocably forfeited. But even a mediocre effort on that paper or test all too often lands a solid grade, sometimes even full credit. I remember from my own experience many times turning in a paper at the last minute after barely having taken the time to massage a rough draft into even the illusory appearance of something final—and all to be rewarded the next week with a grade only a notch or two below what a great paper (and significantly more effort) would have earned. And so it is that our colleges annually release into the white-collar world legions of nervous deadline-appeasers who are quick to dismiss the necessity of high quality work.

Deadlines do matter, and software developers should have at least some inkling of an understanding of their decisions' budgetary consequences. However, a developer's primary responsibility is to his software, not his budget. Often this means standing up to a trigger-happy manager or lead and telling him, “No, you're going to have to wait.” It's a small price and often, in the end, none at all. The world has little need for more bad software.