Never underestimate “hidden” values (or costs!). It always shows up in the end.

…or, “How I learned to stop worrying and love sick days.”

The story goes something like this: I didn’t used to get sick when I was a younger, strapping lad. I lamented the separation of sick days from general time-off (read “vacation”), because I rarely needed sick time.

Recently, I’ve gotten pretty nastily sick. Twice. And I was real pleased I got paid to get better (and not lose my job).

This past week was one of those times, and I was miserable on Monday. Until this year, I’ve never really considered sick days as a real benefit (I mean, yeah they’re a “Benefit” according to HR, but back then, I would have preferred more pay or vacation). It was definitely hidden from me.

As I reflect back on this past week, it made me thing about some other times that I’ve dove in head first and not fully looked at the costs and benefits of a something… and they always come to reward/bite me in the end. When I first thought about this post, I was considering talking about how pre-planning and design seem to create hidden benefits to most people, but I found myself going off on a rant about education of Software Engineers and good practices in software dev. Another time perhaps. :)

Despite my lack-of-rant, most of the hidden benefits/costs are things that can be discovered by doing pre-planning and looking a little deeper before diving in. At a previous employer, it was fairly commonplace to hear, “Well I started doing ABC, but forgot/didn’t know about XYZ feature and so re-invented the wheel/ran into a roadblock.” I’m guilty of it myself; I love what I do, and I usually can’t wait to dive into implementation. I know I could have avoided that.

My mind is drifting off topic some, and I feel like I’m rambling, so I’ll cut this short while my body continues to recover from last weekend. Ugh.

-sean

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.