outward not upward

I’ve been a hacker since before I can really remember. But one common factor present during my whole hacking experience is a tendency toward short-sightedness.

Specifically, the adjectives “quick” and “dirty” are hardlinked to the concept of hackery, and one would be hard-pressed to find such things as “discipline,” “process,” “design,” or, God forbid, “UML” heralded as the flying buttresses of the craft, though crafty it is.

Recently, though, it’s become apparent that the hardasses that do champion these notions might actually have something going for them. And that’s consistency.

As a ninth grader coding one of my first mid-scale projects, I gave little thought to design up-front. Granted, I laid down some basic level and creature design, but as far as software architecture goes, I was the supreme being in a one-man kingdom of ad-hoc-racy (apologies to Cory Doctorow).

It’s taken far too long since then to actually beat a remarkably small set of planning and production tenets into my head. But having now participated in several team projects of a moderate scale, the difference between designing on the fly and planning up-front is obvious, as it perhaps should have already been seven years ago.

Perhaps one reason for this is the ever-present (and altogether true) mantra, “Software is hard.” If a young developer thinks software is just, by its nature, very difficult, will he be surprised to hit roadblocks, to even be forced to abandon many of his cool ideas mid-stream because they simply became “unmanageable”? I certainly wasn’t.

The short of it is this: when writing software, jumping into the code is the worst thing you can do for the long-term health of your system, because all your ideas about how the bits and pieces work together are muddled and half-baked. I’ll be audacious and even claim that the amount of time spent on planning should be greater than or equal to the amount of time spent coding, even on very small projects. After all, even though you might “plan to throw one away,” some ill-conceived artifact of an off-the-cuff approach will linger and haunt until the totality of the project is retired and forgotten.

Perhaps we should let young developers know that yes, software is hard. But it should be hard because the problem under consideration is an intriguing and challenging one, not because ad hoc design has allowed us to glibly paint ourselves into a corner.