Another Programming Blog? Seriously?

"Just because you don't know what the right answer is - maybe there's even no way you could know what the right answer is - doesn't make your answer right or even okay. It's much simpler than that. It's just plain wrong." --Dr. House, "Three Stories"

"Tough decisions made in the absence of information" --A saying around my office

The idea of a programming blog isn't exactly new. In fact, it seems that in the software development world you can hardly throw a virtual rock without bouncing it off of a couple of blogging developers. I'd even go so far as to say that with the ubiquity of stackoverflow, a purely programming technique blog is nearly pointless anymore. So why bother adding content that is almost certainly redundant?

To put it mildly, the subject of "What is the code to implement this technique with this development platform" is well covered. It's somewhat harder, in my opinion, to find good advice and articles on the subject of how to structure your code to not make your life harder in the future. Or how to think about code structure so that the decisions pertinent to your project are clearer and easier to make. Note- I did not say "Easy to make" but rather "Easier to make". If the decisions were easy there would be no need for someone to make them.

I don't intend to post a lot of code. In fact, I specifically don't want to post a lot of code. I think that without code, I'll be forced to focus more on the thought process behind the techniques and concepts rather than how to implement them. Again- implementation is well covered.  Knowing what concepts are relevant and why is much harder because of two facts that I have found to be almost universally true:

1. There are no "right" answers. Merely decisions and the underlying reasons for those decisions.
2. Even if there is a right answer, you likely won't know it ahead of time

Any reader that has made it this far (And thank you for that, by the way) has certainly noticed that these truths not only contradict Dr. House's point above, but reject his statement out of hand. I didn't lead with that quote to present it as a correct- or even viable- way to approach software design and architecture. I have found, however, a prevailing expectation among project stakeholders and sometimes even IT management that this sort of principle applies. This isn't an expectation to be "managed", as the project buzzword goes. This is an expectation to be ended. As software architects, we strive to make the best decisions based on the information we have. Then we go on to refine those decisions to account for situations that we expect, based on our experiences in the craft. But not only can we not account for everything, as I will cover in a future article, we shouldn't even try. Because of that, things are missed. Sometimes it's okay. Sometimes you grin and bear it. Sometimes you kick yourself- assuming someone else isn't already providing you with that service. Whichever way it goes, all you can do is make the best decisions with the best information you can.

I'm here to try and help with that.