Perfect software architecture does not exists !
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.
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…
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 🙂
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.
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”
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 ?