Sunday, April 6, 2008

Application Server Value Proposition

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.


Paul said...

Hi Andrew,

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!

Hi Andrew,
I believe that there is a war going on. I was a J2EE champion back in 1998. I believed the hype. I hadn't read Fred Brooks "No Silver Bullet", but even so I still had my nagging doubts.

Back then I was moving out of Management and masquerading as a Systems Architect. I went to all the glossy J2EE seminars and booked myself into several expensive J2EE Enterprise Architecture training courses with Valtech.

The promise was based on Objects and Frameworks. Back then the idea of an 00 Framework was very new.

Even back then there was decenting voices. In 1997 Alan Kay made his famous Keynote speach at OOPSLA where he slammed Java and C++ as being fatally flawed. I didn't read his speech, and even if I did back then I wouldn't have understood. Back then Objects were still very new to me, and what the gusy from Sun were saying made a load of sense.

It wasn't until I went contracting and had ti face the J2EE beast myself head on that I began to realise that I had been duped. Perhaps innocently so. Maybe Sun didn't know that Java wasn't up to the job or that to use Objects well you needed to really get it!

Anyway, the middleware bandwagon had rolled and J2EE was now a multi-million dollar industry. Who was going to admit it was all built on a false premise. Some people like Bruce Tate was The J2EE Elephant Articlewilling to admit the truth in print. Most chose to stay quite and reap the financial benefits that presented themselves to anyone who had got half way through consuming the J2EE Elephant.

Now, it is self evident that complexity is still with us and buying in technology is not the answer. Yet the trainers, consultants, vendors, strategists, architects etc. have a vested interest in convincing the customer that it still is.

So from a honest mistake (perhaps) we are now trapped in an industry which is dishonest and self serving. Those of us who know the truth are at war with those who would rather keep it a secret. Keep up the good work!

Sometimes I wish I was doing something else for a living :)

Brad Wiederholt said...

Hi Andrew.

This blog is great. Glad you are sharing your thoughts with us.

Anyway -- As someone who has had to endure working with some of these tools, I keep on thinking about the work of a psychologist named Mihaly Csikszentmihalyi who talked about the concept of 'flow' -- that state where you are really into your work, completely absorbed, complete challenged, completely motivated. We've all had flow -- been in the zone and time just flies.

I had listed some of the characteristics of flow to one of our colleagues earlier, but to recap, flow requires intrinsic rewards, a challenge that is not too difficult or too easy, sense of personal control, and immediate feedback on your work.

These J2EE tools, in particular the RAD/Portal environment of my recent experience, go against flow. They break a lot of rules of flow, especially that of immediate feedback. There have been too many times where I've pressed a button in one of these tools, only to have my concentration broken by an unexpected "please wait" message. The tools, and associated J2EE baggage (including vendors), simply get in the way.

I've had the luxury of using a more rapid development environment and language lately (Flex). One of the big attractions for me is that I have regained a sense of flow. I actually feel rewarded by my work again.