05 January 2009

Overengineering

SpringSource tcServer - The Tomcat You Know, The Enterprise Capabilities You Need | Javalobby
I'll never forget the day a developer in my team was tasked to provide a utility class to easily send an email with an attachment. A week later, about 4 more days than anyone had anticipated for the task, we received an Enterprise Archive (EAR) containing the solution. As a consumer of this library one had to open a remote connection to a JNDI library, get a handle to an EJB and invoke the EJB method. The EJB would send a message to a JMS queue which was picked up by a message driven EJB that in turn invoked the javax.mail library and sent the email. Of course the JMS queue was configured to be persistent in a RDBMS, so we had to configure a JDBC data source. The EJB was transactional, so we managed to fit JTA into the mix as well.

What I learned was that development teams during the era of J2EE/JEE:


* often structure their solutions around the technologies that are available

* have a tendency to try to use as many technologies as possible

* when choosing technologies are driven by the desire to try out new technologies while still learning them

* being able to document the skills on their resumes

While my example seems to trivial and over engineered, even ridiculous, it is an exaggeration of common mistakes of over engineered solutions that represent many applications running in today's production environments.