Some years ago, when I first got into the Java/J2EE programming game, I started to learn about application servers, what they were and why I would want to use them. This was in 2001-2003 era, when vendors such as BEA and IBM dominate this lucrative market and open source solutions were not quite ready for prime time.
Now the whole premise of the application server was sold on the basis that, as a developer, it was there to make your life easier and as a manager, hey you could save costs by hiring less expensive developers (dumbing down) you don't need super smart guys because our product almost writes the hard parts for you!
Bear in mind that my background was one of mostly rich client development in a C++/Sybase background - traditional two tiered architecture. In this environment I felt productive and could turn on a dime when changes were requested of me.
When I emerged from the wreckage at the end of the project, I felt battered and bruised and hadn't felt as unproductive since I had graduated some 8 or so years previously. The simplicity sell had not materialized, delivering anything had been tough. This is often the point at which a consultant is brought into the mix and their advice will often be - you need more of our very expensive consultancy because your staff don't have strong WebWhatsit 'Firkin' skills. Much later I learned that this is merely the standard consultant response to anything - make more money. In some ways, I can't even blame them.
Why had the project really been so tough? I had been asking myself this question constantly. We had smart people working on it, they had attended training; but it hadn't been enough. Complexity does not just go away in the development game, it simply moves somewhere else. In the context of this project, one of the places it had moved to was configuration. Integration with application servers is also more complex. In the process of trying to offer more choice (most people see this as a good thing) with 'best of breed' vendors' solutions being pluggable at every point in the stack - all that happens it more complex integration points are introduced, none of which seem to work as advertised.
Also ripe for consideration - and I now see these as more serious contributors that I had at the time, was the seemingly small things such as hefty development environment, expensive toolsets, slow and hard to use. Testing was much harder with container/code deployment model, starting the container and testing inside it requires some considerable time/effort and is a much slower process than testing outside the container.
All in all, configuring the numerous descriptors, server configuration files etc in order to make the thing work, was a bit of an ordeal, and I (perhaps unbelievably) quite enjoyed it and viewed it as a personal challenge at the time. I was stupid - that is not what software development is all about - would I say my company got value from that project - absolutely not.
Unfortunately for me, I had not yet learned my lesson. We progressed with the next, much bigger project at the company, management convinced that our learning curve now put us into position for success. I will save this one for the next blog.