How about a spot of banter about an architectural phenomenon that I often see in various projects? Since I've made the same mistake in many projects, I guess it's okay to joke about it.
The phenomenon I'm referring to is that there seems to be an architecture principle in many projects which says "the more layers the better." The principle is very common in .net and java projects, especially in the projects known as enterprise projects.
Why does this happen? There are many explanations, but the following stand out as the most common:
- "It can be good to have many layers. You never know when a layer might turn out to be useful."
- "Person X / Book Y says it should be like that."
- "Everything should be similar and follow the same structure."
I think all the reasons above are really bad. The first is an excellent example of accidental complexity. Speculation in advance increases complexity. It is best to resist speculating and make things as simple as possible instead so that they are changeable when, or if, needed.
The second reason is lacking "context is king". No solution is always the best; it obviously depends on the situation.
But perhaps worst of all is the third reason. The code should not be similar because there are different problems and different situations or if it can be similar, it sounds like a serious violation of the DRY (Don't Repeat Yourself) principle. Probably it should not be hand written at all.
Someone wrote a while back that "Architecture is like lasagna. The more layers, the better. "I totally disagree, both in terms of architecture and the lasagna. The taste is not in the number of layers. In fact, that quote makes me long for spaghetti.
What are the drawbacks when having too many layers?
- When something is changed, there is a tendency that the change affects more than one place in the code due to all the layers.
- You get tons of completely uninteresting code which means that there is more to read and it takes longer to locate what you are looking for.
In short, it becomes more expensive to maintain.
There seems to be a common tendency for developers to follow a cyclical pattern. At school an early project starts with all the code in a single layer.
Then you move on to an extreme amount, maybe eight to twelve layers, finally becoming situational and allowing the solution to the problem decide the right number.
The approach I recommend is that you do not focus on layers at the start of new projects, but focus on understanding the problem and describing the solution as simply as possible.
As the need for more layers proves itself you add them, but only after having critically evaluated the value relative to the cost.
You won't win by using more layers than anyone else.
(First published in Swedish here.)