Unless you happen to be Don Knuth, you have probably written bad software. But believe it or not, bad software is good for you.
One of the funniest blogs for developer is The Daily WTF. For normal people like my wife it is of course completely and utterly baffling, containing, as it does, words arranged in monospace fonts with punctuation where it shouldn’t be (sometimes with more punctuation than any text has a right to have), different lines indented in different ways, and if you’re lucky some words get to be printed in blue or red.
The Daily WTF’s premise is simple: developers enjoy a good laugh when we see badly written software. The laughter is usually accompanied by a fervent prayer muttered under our breath: "We hope by all that’s holy that we didn’t write it, and we pray that it isn’t part of the application we’re currently developing." The blog has a post a day that lampoons some source code, some interaction between a developer and other IT personnel, or some development-related happening.
Consider this saying: "You learn from your mistakes." Though a bit trite and clichéd, it does hold a grain of truth. Think back in time to a really awful bit of code you wrote. What happened when the inevitable bug report came in, and you investigated, and noted with horror what your younger self had written? You broke out in a sweat, your eyes dilated and you uttered the immortal acronym WTF, but in a decompressed form. Maybe you were able to cover it up, maybe it had to be written down in all its glory in the bug report’s commentary and then you had to go past people in the hallway who would fall silent and watch as you went by.
But I’ll bet you’ve never written code like that ever again.
Another example maxim: you only learn by doing. You know, you can read all the books and erudite exposition explaining how test-driven development helps you write better software, but you won’t internalize those lessons until you actually start writing tests. Until then it’s merely a nice thought experiment with no contact with reality. But how many times will you write bad software, or make the same coding mistake, or forget to check a fix in, before you start to wonder whether having a test suite could actually save your bacon? And guess what? Once you start with a unit test suite, you’ll be adding code to it all the time. Your code will get better. You willl stop making the same mistakes, (but make different ones and probably be able to fix them faster.) And most importantly, you’ll learn to rely on the tests that are run each time you check your code in.
You see, we do have a real need for bad software. It is only through bad software that we get better tools, better algorithms, better methodologies.
Think about it another way: it took several iterations of really bad software before Microsoft launched their Trustworthy Computing initiative. And it took them awhile to see the value in designing the CLR. The CLR demonstrates that it is harder (but not impossible) to write unsecure code with managed code and the .NET framework than with the C run-time library and pointers galore. It took an analysis of Diebold’s bad voting machine software to make us realize that hanging chads were the good old days. It takes bad software to crash a Mars probe into the planet and thereby waste $250 million and nine months in one glorious thud. It takes bad software for us all to appreciate that it’s new software we like writing, but that the steady money comes from software maintenance.
Bad software is everywhere; we have to live with it. It permeates the programs we use every day, it infuses the components we use, it pervades the society we live in. It forces us, as developers, to strive to better ourselves and to write better code. (If it doesn’t have this effect on you, then maybe you should go do something else!)
It takes bad software to make us appreciate the good software. Best of all, it gives us a good laugh every day!