Today’s little mini-rant is brought to you courtesy of software developers (and I use that term loosely) who think that the purpose of writing a piece of software is merely to get the computer to do something.
Wait – that *isn’t* the goal?
Well, think for a second. If you want to get the computer to do something, AND you only have to do it one time, AND you get to throw away the source code after that one run, then yes, I suppose that your only goal should be to “get the computer to do something”.
Unfortunately, that’s never the only goal, and increasingly that’s not even the primary goal:
- A lot of software is written merely to tie together two or more OTHER pieces of software that actually do something. Mashups, integrations, communications, API calls, etc. The goal is to enable communication, not “do”, per se.
- Software is built and is used as part of a lifecycle that includes thinks like “testing” and “maintenance”. You may have heard of these concepts while leafing through Wired magazine. The goal here is to reduce overall lifecycle costs and increase overall lifecycle quality.
- Way more than half the time, your software’s primary “do” purpose will change – as a result of market opportunity, competitive pressure, client changing their mind (yes, it does happen) – whatever. Your goal here should be to make the inevitable changes easy and cheap to implement.
So what drives me to the Advil bottle? Developers who write the “quick and dirty” 1000-line function, with every assumption known to man and God baked into the code. Trying to change it is like trying to work on a Jenga puzzle while wearing ski gloves.
Quick and dirty is fine – if you’re following good software development practices, which most good devs have internalized to the point that you don’t need to think about it much anymore. Modularize, use single-purpose functions, isolate dependencies, reduce assumptions, DRY, etc.