Facing the Reality of Software Development

Last weekend, Jeff Atwood wrote about the origin and signifigance of “Coding Horror,” the name of his blog. Though the name and logo were literally borrowed from the book Code Complete, Jeff points out that there is a deeper meaning:

One of the most striking and memorable things about Code Complete, even to this day, is that Coding Horror illustration in the sidebar. Every time I saw it on the page, I would chuckle. Not because of other people’s code, mind you. Because of my own code. That was the revelation. You’re an amateur developer until you realize that everything you write sucks.

YOU are the Coding Horror.

This is an issue I can certainly identify with; to me, it resonates strongly as one of the central conflicts that we all face as software engineers.

It’s one thing to lack an understanding of how to develop good software well — this makes you a novice. It’s another thing to possess that understanding and the discipline required to apply it. That makes you skilled. But a professional software developer rarely works alone, and often it’s this fact that forces us to become “coding horrors.” Sure, in an ideal world we’d all do everything correctly — we’d never knock together a quick hack to meet a milestone if there were a more permanent (but more time consuming) and more correct fix available. We’d never check in half-working code that met the letter of the specification but would break spectacularly if a user performed operations in a slightly different order, no matter how large the deadline loomed. We’d be software developers truely dedicated to the perfection of our craft, and sales, marketing and customer relations be damned.

But we live in the real world, and in the real world we need to concede to the limits of practicality. Software is complex. Though individual problems may have a simple academic solutions, in the context of an actual project those solutions might not be as simple, elegant, or even possible. Sometimes we are forced to take the less-optimal solution even though our principles of correctness are howling in protest. It’s even possible for a developer to trample those principles without even knowing it, or indeed while merrily thinking he’s doing the right thing. It’s easy to pick up poor habits from elsewhere in the code (see “Don’t Read Source Code”) or by talking to a colleague who himself has a flawed understanding.

Coping with this simple fact, that we will all write code of sub-par quality through neccessity, chance, or both, is the constant challenge we must face. There are simple techniques that can help alleviate the pain, of course: take the time to study a change and its ramifactions, use those “excellent written and verbal communications skills” you’ve been padding your resume with for years and actually talk to people (plural!) who may have pre-existing knowledge of the area you’re working in. “An ounce of prevention,” et cetera, et cetera. Refactor when you can, don’t let code debt build up beyond manageable levels. Understand that sometimes “good enough” is all you can get for the time being.

Most importantly, try not to develop personal attachments to your code. It helps avoid bruised egos when your fellow programmers discover a bug with some code you wrote — it happens all too frequently, especially when the bug was authored by a senior developer and stumbled across by a junior; flaring tempers don’t solve the problem. Try, instead, to understand what part of your approach to the writing of that code caused you to create the bug — a simple typo, incorrect documentation elsewhere? Perhaps it was based on existing code — then the bug probably exists and needs fixing there, as well. We are logical creatures, approaching the problem rationally is well within our talents and helps us improve at our craft.

It is possible that we’ll always have to deal with the compromise between what is correct from a pure software engineering standpoint, and what the demands of business require. Perhaps the industry as a whole cannot operate otherwise, or perhaps we’re simply doing it wrong. I’d be very interested to hear any comments you might have, so let me know.