Do you have any good examples of "architecture for architecture's sake"?

Question

Just listening to this week's podcast and thought it would be nice to group together some of your experiences where you've seen the "architecture" side of design dominate things a little more than it should.

Java often gets a bad press in this respect, and an increasingly bad press as the perceived complexity of JEE increases. My Java experience against time graph nose-dives significantly after 2004 so I don't feel qualified to comment.

My most recent experience is with an architect desperately trying to accurately represent an object model in a set of (relational) database tables (happened to be Oracle). The result is a database schema that's impossible to query efficiently without first pre-joining a bunch of tables (in materialized views).

Answer 1

The company I work for produce an application which has a SQL Server backend database. One of the main tables requires joining to itself six times before getting any meaningful data out of it!

Answer 2

Oh yes !

In my last job, working on a quite large project, we had an architecture team which put in place the whole framework we used. They designed a custom ORM (circa 2000, Hibernate wasnt as ubiquitous as today) and a custom RCP framework based on Swing.

The ORM wasnt all that bad. They were just overly concerned about circular dependencies so in some cases we had a pretty bad time to express our domain model, as the business did require circular dependencies (business objects could flow both ways between different administrative units).

The Swing framework was hell. They tried to implement a component model, with something looking a bit like a hierarchical controller. It looked really good on paper : you can have component that can be reused. Model, views and controller were clearly separated. But in reality, the framework didnt provide enough flexibility, so we had to keep references to JComboBox to get the data through the abstraction layers. We had to write 4-5 classes for every little piece of UI. In some cases it took days to add a checkbox on a form. Debugging was awful as the process flow was going through 15-20 classes for every simple operation. Amazingly, performances were OK.

Worst thing, every Swing component was wrapped in an abstraction layer "in case we want to change the UI toolkit" !

Answer 3

If you haven't read Joel's article on Architecture Astronauts (the Live Mesh one), I recommend it - it's a good read about this subject.

Answer 4

In every place I have worked for the last five years!

My official job titles have contained "architect" for the last six years, but, on a grumpy day I am more of an anti-architect, on less grumpy days I am a "minimalist architect".

If there isnt a good staighforward and obvious reason for a component, framework or feature to be there then I drop it!

On the occasions where I have been overruled the extra uneccsary architecural features have always turned out to be the biggest problem area.

Answer 5

This was on reddit recently, with a good "yo dawg" joke.

Introducing: RequestProcessorFactoryFactory

Reddit discussion here

Answer 6

A really good parable appeared on Joel's discussion group on this topic a few years ago. The story is called Why I Hate Frameworks.

Answer 7

I always thought This Hello World implementation was good, too.

Answer 8

My favourite is "auto-architecture". Basically just a set of rules that if you follow the architecture falls into place correctly..... apparently.

So this results in every object having an interface regardless of whether it needed abstracting and a factory (no new() for you!) for EVERY single service... sighs.

Answer 9

No.

Shouldn't the architecture be subordinate to the requirements?

Answer 10

A friend of mine works on a large scale DB where everything has to descend from the custom class "Any"

/shudder

Answer 11

My pet peeve is "architects" who don't understand relational concepts and try to make things work in an object fashion when databases perform better in a set-based fashion and should be designed to be used that way. (Databases should not be designed by object oriented programmers turned architects, they should be designed by database specialists) And architects who think it is more "Elegant" to put multiple things in one main base table (overgeneralization) and then end up with over 100 foreign keys to that table and every query referencing it and a major performance nightmare (as well as a ridiculous process to go through to delete a record).