Advantages of Bad Code
Not every program is a masterpiece of ingenuity. Software doesn’t exist to be a perfect shining diamond – it facilitates something else, and that something else is what we care about. The intense 3D game you developed – fantastic! Your massive accounting report - it should rock! Your child’s digital storybook – it should be glorious! But the program you’re going to write today? It’s messy, it’s complex, it’s slow, it’s O(n^2), it’s unrefined and awkward, and that’s okay. Let me tell you a story:
The Parable of the Two Programmers
A manager asked two programmers to compete to write a program to solve the same problem. “This is a tricky problem,” the manager said. ”The one of you who solves this problem will get a promotion.” One of the two programmers thought, “This is my opportunity to show how good I am!,” and set to work analyzing the problem thoroughly, refining data structures, selecting the correct algorithms, and isolating every edge case. The programmer labored over the program carefully, wrote unit tests, validation suites, and finally delivered a fully documented, functional masterwork. The manager replied, “This is great, but I’ve been using the other guy’s program for a few weeks now.”
Why is bad code okay?
We all want to have good code, but good code has a cost. It takes lots of extra work, time, and refinement to produce ideal code. In the story above, I purposefully left out the criteria that the manager used to decide whether the program worked or not. Ask yourself, the next time you start a project: how do you know for certain that what your client asked for is actually what they want?
Unless you’re gifted with perfect foresight – and all evidence suggests that nobody is – you’ve just encountered part of the reason that SCRUM and AGILE exist, the reason that people warn you against premature optimization, and the reason that most IT projects fail.
They all come down to a key cause: it’s really difficult to identify what will make a project succeed in advance. In some cases, ideal algorithms matter. In other cases, exhaustive correctness matters. In other cases, flexibility matters. You can guess, and you can listen to your client, but you just don’t know which item will turn out to be the key when you start. Clients are often just as wrong as we are! That’s why it’s useful to produce a solid program, one that may be a work in progress, then refine it.
After decades of lessons in professional software development, the general consensus today is that rapid iteration creates better software than attempting to perfect your design in advance. The point is to get your program to a healthy state, where the program is usable and the code is maintainable, then use and maintain the heck out of it! If you want to provide the illusion to your customer that you produce perfect code on the first try, release it a dozen times internally, use it, refine it, and only then show it to the client.
Rather than trying to perfect your software up front, learn how to write something simple, easy to understand, and modular. The programmer who’s tinkering with a finished product will have a much easier time deciding on optimization than the programmer who is still living in theory land.
