How to build maintainable systems: Simple design

Wonderful post by tirsen on codehaus blog, I very much agree with him.

I'm not saying that simple designs by some divine judgement are better designs (I do believe so, I just don't want to start that particular debate again). There are other much larger problems with complicated designs when it comes to implementing maintainable systems: complicated designs usually become poorly understood and therefor poorly implemented.

I've seen this many times in the field: Some hot-shot architect works for an intense period early in a projects lifecycle and produces some really hot-shot, ultra-cool, super-slick design that solves everything that the system would ever be conceived to do and then some. Job done, the architect leaves for his next hot-shot assignment (he holds himself too high for such profane tasks as, bah, implementation).

Left on the project are a bunch of more junior people who are up to the task of actually delivering the system. If they ever understood the design in the first place they are certainly not understanding it good enough to be able to maintain it when exposed to realities such as time-pressure, performance problems, inconsistent requirements and so forth. The design starts to break down and technical debt accumulates. The biggest problem now is that not only has the design broken down, they are also dragging around a massive framework hampering their every step.

I have been to places that had frameworks of hundreds and hundreds of classes that when it came down to it did the equivalent functionality of about two mid-sized classes work. I kid you not.

Some warning signs to look out for:

"We're building a generic framework so it will take a little longer to deliver the first project. But then we will be able to reuse all this stuff so we'll save time in the long run." (Building reusable software is many, many times more difficult, expensive and time-consuming than one-off software. Is there really a business case for a reusable framework?)

"Let's build it so that all this functionality can be accessible from any possible client." (Technologies like web services or CORBA has a huge up-front cost in terms of complexity. It's better to build the remote interfaces when the client actually exists.)

"Make the customer disappointed the first time, because they will be more than happy the next time." (Are you sure you will get a next time?)

"We want to use a rules engine so that the business can easily extend the system in the future." (Even a rules engine requires programmers to write the rules.)

"It might seem a little complicated for this simple project, but if we stick to a standard technology we can be sure to find developers that can maintain the system in the future." (Nobody can maintain an unmaintainable system, standard or no standard.)