How many times in the last couple of years have you seen an initialization servlet (a servlet which is used only once with the load-on-startup parameter) although a context listener could have been used in its place? How many times have you seen a JSP full of indecipherable scriplets though equivalent taglibs were available? How many times have you disagreed with someone who wanted to talk you into using DTO regardless of your application’s needs?
I could go forever like that but the point is: this is bad and this needs to change. I personaly blame this behaviour on two things.
First, technologies change daily. This is a fact. And the more technologies you know, the more it takes time to stay knowledgeable on them. At least it is how I convince myself why I was not able to teach me .Net in the last years: because I had to stay up to date on so many Java/JavaEE subjects. That’s the reason for init servlets still being in use although listeners are available since JavaEE 1.3. Is it bad? Perhaps not so much, but why use a Ford T when you got a brand new Porsche? And people maintaining the code you developed will always wonder the reasons behind this choice (and sometimes even your capabilities).
Yet, this is not the same thing as always using the newest feature of the latest version of the hype framework of the moment, something I’m also opposed to. But when a solution is mainstream, you should have in your mind as many of them as possible, and know their respective pros and cons.
Second, most of the developers and architects I know (including myself) tend to have an rigid mindset. This translates to always applying the same solutions, whether taught by a guru, by experience or just by oneself, regardless of the context, because they worked once. That’s why many people “just” use DTO although DTO were only needed when using EJB entities, because those entities couldn’t cross application layers and were confined to the EJB container (see my previous DTO in anger article). Today, you should consider using DTO only when there’s such need and not by default. On the other hand, when you discard a technology/solution, it’s final, even though it may have evolved and finally reached its goal.
In conclusion, I would advise everyone that wish to be successful in software to have two mottos: stay up-to-date and think in contexts. I know that depending on your implication and personal situation, staying up to date is more or less easy but you should picture it not as a black and white goal but as a gray scale instead. As for the thinking in contexts side, well, there’s no reason not to do it.