OversolvingPoorDesign

January 23, 2007
[I'll admit, it feels a little like I'm taking some liberties in the following text, but there's something to it that's resonating with me that I wanted to try to capture. If you've got a thought, shoot me an email or a comment]


Working with code always requires a design decision of some sort. What code will I add/change/delete, and where will I do it? Typically, inexperienced teams make these design decisions on the fly, when they're needed, but they make poor choices and the codebase becomes buggy.

What's interesting to me at this point, is that instead of reacting to “we don't design well on the fly” with “let's figure out how to design well on the fly”, they react with “let's design well ahead of time so we won't have to know how to design well on the fly.”

Then they create a design process that is heavy enough to be time consuming enough to be too expensive to actually implement on the fly, when design decisions are needed, so all they are left with is their informal design abilities, which haven't been improved, and the codebase suffers.

What's even more interesting now, is the tendancy to not dump the formal design process as a failed attempt, but to blame themselves for not being disciplined enough in using this process, even though it seems to have shown it's the wrong tool for the job. Formal design gets a revamp, and the undeveloped skill of making good design decisions on the fly remains undeveloped, and the codebase continues to suffer.

Some teams will eventually start to improve their ability to make good design decisions on the fly without a formal process, but then still keep the formal process around and now start making some sort of arbitrary distinction between tasks that get designed by a formal process up front and those that are somehow different enough (but really aren't) to be okay for the informal design. Now we have process duplication, which may not be ineffective, but surely is wasteful and risks the same sorts of problems that duplicate code does.

tags: ComputersAndTechnology AgileDevelopment
comments powered by Disqus