I like the idea of thinking ahead enough to develop a “walking skeleton” as Alistair Cockburn describes it, http://alistair.cockburn.us/Walking+skeleton. He didn’t invent it and others have popularized it but I first heard of it from him. This is very useful to show progress, define interfaces and allow concurrent development more easily because it removes dependencies.

Both overdesign and underdesign can get you in trouble. So making the time for some thinking and exploring (especially when you are making something totally new) is important. But that is no excuse to over-embellish a design. Looking ahead, just far enough ahead is what I strive for.

I have worked on projects that have spent so much time in requirements and design that they did not have the funds to implement the project. Agile seems in some cases to be an overreaction to this problem and the knee jerk reaction to the extreme other end of the spectrum.

The architect whose story I was recounting was not making a duct tape solution in my opinion. Instead he made minimal changes to improve the system and left the inconsistent existing logging code intact. Not ideal, but not harmful, either. He didn’t increase the entropy of the system by his “fix”. When you can fix a problem this way, you are lucky. As a matter of principle, if you can shore up your architecture, make changes and enhancements, while continuing to encapsulate the poorly designed parts, you are doing OK.

Too often, however, duct tape solutions are applied deep in the bowels of systems. As a consequence, code and data become even more tangled and incomprehensible. And it becomes increasingly difficult to make repairs or enhancements.

One of the biggest challenges I see is that corporations care about little more than shipping code. While I agree that shipping code is job #1, there are many other important jobs (let’s call them job #2, #3 and #4) that, while important, are more often than not, neglected. Sadly, focusing solely on job #1 results in much accumulated technical debt which, over time, burdens the system and can ultimately prevent job #1 from being completed. So what to do? Well, you can achieve almost anything if you use enough duct tape! But that does not tickle the right part of my brain!

So I know how it feels to want to land the plane, take it apart, and rebuild it piece by piece. But sadly that is never practical despite the obvious benefits. So we’re left with architecturally ugly solutions that are applied to keep the plane flying, regardless of the technical debt it might incur.

I have, however, been associated with shops where OOAD is a valued activity. I remember a comment that a friend once told me, “Once you work for an organization with a mature OOAD methodology, you’re never willing to go back to the OK Corrall style of software development.