Glossary

I have been big on the idea of creating a glossary of the terms and jargon that are embedded in a specific client's problem domain, and doing this very early in the project lifecycle. The justification is that these terms are often thrown around early and throughout a project, but their meanings are not all grasped by everyone until much later. Also, the people on the client's side often disagree among themselves about particular terms' definitions. This lack of clarity often results in subtle bugs in the system, or simply in expensive rework downstream. A quick search shows that some requirements methodologies (such as Steeltrace and maybe others) already encourage this. Putting it into practice seems like a lesser priority to some, but I think this is one of those little things with a big payoff that's hard to measure.

I Run Free Software

Listening to my favorite podcast, lugradio, makes me feel like I've sold out to the evil empire. Then I realized, hey, I run free software! It's called Windows. I have never paid penny #1 for it in seventeen years. OK, maybe its cost is embedded in the price of the hardware I buy. Well, most of those in the rabid Linux community have paid that same price. They just took the extra step of not using it after paying for it, then installing something that is often unsupported by major hardware vendors and makes their lives much more difficult. Their goals are more noble than mine. Mine largely entail getting my job finished every day.