So what if many J2EE applications are "over-engineered"? Surely they'll be responsive to future needs, highly maintainable, and highly performant?
Unfortunately, this is not the case. This is one of the costliest myths associated with J2EE. In reality, over-engineered applications are more likely to be bloated, buggy, unmaintainable, and slow. The "over" in over-engineered means "wrongly."
In this chapter, we'll discuss common causes of over-engineering in J2EE application, and its costs. We'll examine the benefits flowing from our goal of simplicity.
Unnecessary architectural complexity is bad. Complexity costs money and delays deliveries. Complexity provides fertile ground for bugs, and makes it hard to get rid of them. To take just a few issues:
Every line of unnecessary code must be written, tested, and—still more expensively—maintained for the lifetime of the application. Writing and maintaining every line of unnecessary code consumes resources that could better be spent on the problem domain.
Complex architectures and code often prove to be inefficient. Too many layers, too much abstraction, too much remote calling: all contribute to poor performance.
Complex code complicates the build process and often creates a dependency on complex tools.
Complex code is hard to understand, making it hard to introduce new developers to the project. Far too much effort goes into understanding and maintaining the complex architecture, and ...