Man! This is cool: check out the lib directory of the latest IntelliJ EAP drop: "picocontainer-1.0.jar"!! They're using PicoContainer internally! That is so cool!

IntelliJ IDEA has given me so much during the years, I'm so happy to give something back.

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.)

If I see another DTO in a non-distributed webapp again I think I'm going to throw up.

Data Transfer Objects are meant for one single thing, transfer data over a distribution boundary. Extremely few webapps benefit from being distributed (as opposed to clustered which is an entirely different thing). Everybody seems to know this by now. So why do I still see all these completely non-distributed webapps with DTOs all over the place!?

You would think that people start thinking something just gotta be wrong when a significant portion of their system is just about shuffling data in and out of DTOs. Or when the domain model is left completely atrophied and looks more like a relational database schema expressed in an awkward Java syntax. Or as their carefully crafted architecture just falls apart in a mumbo jumbo of completely unmaintainable procedural code.

Oh nooo. They are the perfect excuse for creating objects completely without behaviour or responsibilities, approved and signed by the uber guru of enterprise architecture himself. "Hey, if Martin Fowler says I can do objects without behaviour then I can bloody hell do them all the time!"

Martin, you're a great bloke and I don't mean no disrespect but couldn't you just have left this bastard of a pattern out of your books! People just can't handle it responsibly.