Pre-investment in order to do less later is always worth it.

Several times I’ve had colleagues who have stated to me that, while they would like to spend the time working on these “schoolwork tasks”, but those were “from the classroom, and this is the ‘real world’.” I couldn’t disagree more. “A stitch in time…”, “An ounce of prevention…” and such truisms are all true, especially with regards to software development.

I’ve stated before that I am of the opinion that successful projects take the path of least resistance, as long as it a long-term “least resistance”. Short term solutions are a treacherous road, and should be avoided if possible. (Hmm… Perhaps a better term would be “path of least overall cost”, but that just doesn’t flow as well.) :)

Regarding software development, so many headaches are solved by doing the up front legwork that we learned that we’re supposed to do when writing code. In-code commenting, pre-designing architecture, legible code, and (gasp!) documentation are not just “good ideas” to me; they are requirements of successful software. Remember, not only do we need to deliver applications, we (read, “Developers as a whole”) need to maintain them as well. It is just as important, if not more so, to have maintainable code as it is to have “correct” code. Please, think of the childre– er, the next developers that will maintain your code.

This is true of non-software projects as well - how often have people looked back on what was started, and said “What in the world were we thinking?” when trying to fix something? It’s always worth that time to make sure one can look back and know why a decision was made, so one can always reconsider it with new knowledge.

Similarly, having fail-safes in place to make sure that changes to a project do not break other aspects of its goals are essential. Generally, a project of any appreciable size takes on a living, changing nature, with many of the small details or requirements never being fully documented or considered. Making sure that later changes don’t have far-reaching consequences on inter-linked aspects of a project will save much wailing and gnashing of teeth. In software development (for you coders), I’m sure you recognize that I’m talking about testing, especially automated testing. The fail-safes in place are so essential because they will help you continue to forge ahead with the project in question without needing to look over your shoulder all the time.

But when you do need to look back, knowing how or why things exist they way they are will make diagnosis infinitely easier. When repairing anything, it is always easier to read the manual before diagnosis, as it were, then to reverse-engineer the object (possibly erroneously!). This is where all that up-front work you spent documenting (or at least noting) will pay off.

And when you get to go home at 5 o’clock with minimal hair-pulling or teeth-gnashing, you’ll quite the happier person.

Saturday, April 21st, 2007 @ 1:05 pm Code Life Lessons, Software Dev
RSS 2.0 Trackback