To design software is to attempt to understand the very logic that composes its parts. At best as software developers we make crude approximations as to the intentions of our applications. Even the most thorough requirements gathering cannot account for every last permutation, in much the same way that unit tests don’t guarantee that your system works.

Despite such an overwhelmingly bleak appearance designing software is not a futile attempt. In fact, quite the opposite is true. Software design is akin to a game of Go in the respect that we must make each move knowing only for certain what has already happened and at best anticipating what the future will hold. But like Go, designing software is not guess work. There are proven strategies and patterns for both that tip the odds in our favor. In this game of software design we can learn from our past successes and failures.

In this upcoming Fortnightly series I will present to you some of the tips and tricks I have acquired over the years. Some of these tips I learned the easy way; most, however, I learned the hard way. I don’t claim to adhere to these tips scrupulously, I post theme just as much for myself as everyone else. And with all things software design keep in mind that “never” rarely means never, it “.. is more what you’d call guidelines than actual rules.”

So fire up the RSS reader, site back, and enjoy.