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 that is maybe useless. On the other hand, 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 drives to a new feature. This line length represents the cost to produce a new feature.

Let’s think of how we can represent a set of features 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 everything. You may fail on one point that screws up everything. See the example below:

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

Too much extensibility

One of the most common mistakes is to oversize architecture. Let's say your boss asked you to create one feature with four satellite features. Why create a gas plant? This frequent over-engineering is due to our big egos :)

Why "extensibility"?

Someone asks you to create two features, one aggregating the other. It is a short-term project for short-term usage. The question is why use extensibility? You exceed delay, money, maintenance tasks, and many other metrics that can deprive you of your year’s allowance.

Blank architecture

You may see a fully functional and complex architecture that ultimately goes unused. Maybe your first plan was to embed two features and one was suppressed. Maybe the developer took delight in creating a nice architecture. We can also speak about "anchor" that stays in the code without reason  except politic or "just in case."

Copy paste

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

You might read:

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

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

Original post:

http://www.alphablog.org/2012/08/04/perfect-software-arcitecture-does-not-exists/