Low cohesion, modularity, dependency inversion, responsibility, interface segregation, overengineering, stovepipe syndrome, silver bullet or shotgun surgery… All of these techniques may lead you to the best solution but the mirror edge is quite thin. At one extreme you will provide an architectural marvel, maybe useless. On the other you may create a genie in a bottle. This article will try to draw some typical situations of the real development world. We can symbolize a software feature by a circle and, in a normal production flow, a line that drive to a new feature. This line length represents the cost to produce a new feature.

Let’s imagine how we can represent a set of feature in our day to day projects.

Low extensibility

This pattern is typical to a little architecture that orchestrates too many features. It might be “perfect” if you were not in the middle of your project…

Extensibility failure

Think about a great architecture that allows pretty much things. You may fail on one point that screwed-up everything. See the example below:

You have a perfect modular system, with an interface segregation and an injection system that allow to supply services bad thing is when you see “new Concrete();” directly in the module code 🙂

Too much extensibility

One of the most common mistakes is to oversize architecture. Your boss asked you one feature with four satellite features. Why creating a gas plant? This frequent over-engineering is due to our big egos 🙂

Why “extensibility”?

Someone ask you to create a two feature, one aggregating the other. It is short term project for a short term usage. Question is why using extensibility? You exceed delay, money, maintenance task, and many other metrics that can deprive you of your year’s allowance.

Blank architecture

You may see a fully functional and complex architecture which is … not used. Maybe your first plan was to embed two features and one was suppressed or the developer took delight in creating a nice architecture. We can also speak about “anchor” that stay in the code without reason  except politic or “just in case”

Copy paste

Once pipes created, you might want to do quick job by copy pasting and adapting a bit… You fall in an Anti-Pattern methodology error. You multiply pipes and multiply possible maintenance. Why not factorizing ?

You might read:

http://en.wikipedia.org/wiki/Yo-yo_problem
http://en.wikipedia.org/wiki/Anti-pattern