Why Enterprise Java Projects Turn Into Over‑Engineered Monsters

You should ask an enterprise‑level Java architect about this question.

For example, simply printing "hello world" in the main function is too procedural and low‑level.

You need to encapsulate it in a class called Printer, which has a member method named print.

But a single class is too simplistic; what if you need different implementations later? So you add an interface, PrinterInterface.

However, an interface has no implementation, so you need a default implementation. Hence you add an abstract class, AbstractPrinter, implementing PrinterInterface, and let Printer inherit from AbstractPrinter.

Now that you have this hierarchy, how do you create an instance? Directly new Printer()? That's too low‑level and creates implementation dependency. Instead you create a factory class, PrinterFactory, which returns a PrinterInterface instance, hiding implementation details.

But PrinterFactory itself is an implementation class, which is also low‑level, so you introduce a PrinterFactoryInterface and an AbstractPrinterFactory.

And inside PrinterFactory, how do you instantiate? Directly new Printer()? Still low‑level, still implementation dependency.

Finally, assembling all these pieces in code becomes messy, with many new statements—still low‑level.

Fortunately we have a sophisticated tool called dependency injection, which externalizes object wiring into configuration files. Of course you don't reinvent the wheel; you configure Spring. With all those libraries, command‑line or IDE project management isn't enough—you need dependency management like Maven or Gradle.

Finally, how do you pass the thing to print into the program? Hard‑coding? Command‑line arguments? That's low‑level; you should put it in XML.

XML alone isn't enterprise‑grade; you also add DTD validation.

Then you encounter XML parsing. Directly using a parser in code is low‑level; you must write a wrapper with interface, abstract class, implementation, factory, etc., to avoid implementation dependency in case you need to swap parsers later.

Thus the final product is a slew of configuration files, many JARs, and a compiled program of about 200 MB.

The IDE needs 300 plugins; opening the project taxes the disk and consumes 2 GB of RAM, with plugins constantly prompting for upgrades.

Oh right, before all this you also have to draw UML diagrams.

Three years later, the project is finished, deployed to the client’s server, and immediately crashes with a flood of stack traces. The server runs JDK 5 while the new project requires JDK 6. When you ask to upgrade, the client says they cannot because another enterprise solution they use only supports JDK 5, and they berate the architects for not anticipating the JDK change.