The Door to Nowhere

Ever seen something like this:

see more Epic Fails

It's one of those things you wonder... what were they thinking when they designed something silly like that?

You see examples of this all the time in code... hey, I'll admit it, I've *done* stuff like this before.  You build an opening for extension to something that can't possibly exist in your application.

This is one of the reasons I believe lean software development is so difficult.  Anyone can walk by this door and notice that it has absolutely no conceivable use besides making it easier for someone to fail at suicide.    However, layer upon layer of abstraction sits in our code today with absolutely no conceivable use except that it's "abstract" and "extensible".  Architects draw pictures of nicely abstracted applications, neatly separated concerns,  and built in abstraction for extensibility.  They then look at the picture, pat themselves on the back, and then hand it off to a peon developer.

Lord Architect: "Here developer, all you need is right here, just code it up.  It shouldn't take you longer than an hour."  
Programmer: "Why do I have to build three classes just to build a calculator that can add and subtract?"  
Lord Architect: "Because around here we use interfaces for everything so it is extensible."
Programmer: "But you have a method in the Calculator interface called, checkSpelling... isn't it a calculator?"
Lord Architect:"We design code for re-usability and extensiblity.  This fits with the long term design concept and it's already been approved.  We can remove it later, but write it like that for now."

Bottom line, building software is not like building a bridge, or as in the example, a mall with doors that make sense.  However, there are striking similarities in the finished product, the difference being that, in software, they are a lot harder to recognize until you get your hands deep into the code.

 While not a silver bullet, there is a way to avoid a pitfall like this and it comes from the book Practices of an Agile Developer.  Architects must write code.  It is a lot easier to see the stupidity of an idea as it is being built than trying to work with it after the fact.

An addition of my own, developers must challenge the architect when something doesn't make sense.  Most developers are just as qualified to be architects as the architects themselves and they can often see waste as they are building it.  I guarantee the construction workers who installed this door said, "This is pretty stupid."  If you are in an environment where architects design applications but don't code, the onus is even greater upon the developer to raise a concern if something doesn't make sense.  Architects, no matter what they think they are, are not gurus or gods of programming.  If the design doesn't make sense, they should be open to the idea that what they designed won't work in practice.  A mature, professional architect should not even want a programmer who is just a robotic extension of themselves. 

In addition, if you are a programmer, you are expected to think, not just type as fast as you can to get the architect's design down on paper.  It is unacceptable for a developer to say, "This is stupid" but then build it anyway.  If they ask a question, maybe there actually is a reason and they can be much more satisfied in their solution.  Working together and fostering an environment of open communication where people give and take constructive criticism is essential to producing applications that do not succumb to problems like the Door to Nowhere.