Moore's law has certainly not been applicable to developer productivity if the results of a recent survey we conducted are an indication.

IT professionals responding to the survey said their number one challenge is the slowness of application development cycles.

Sound familiar? It should do since this has been the number one challenge facing IT organisations since IT was invented.

Why is this an issue? Because slow development means expensive development and maintenance, longer delivery times and increased business risk through the inability to adapt fast enough to business change.

Adoption of the J2EE architecture as a standard platform for delivering applications has done nothing to improve this situation. There is no silver bullet to solve this problem, but wise choice of application architecture, development process and development tools can dramatically improve matters.

If you look back into the history of software development there have been few real breakthroughs in developer productivity. Each "generation" of language and tools has improved productivity to some extent, but in general the complexity of the applications being built has more than offset any improvement. Only the introduction of enterprise-class 4GLs, really delivered productivity benefits to business application developers, but at the cost of some level of “proprietaryness”.

The J2EE platform has emerged enshrouded in a mist of standards in an attempt to kill once-and-for-all this problem of vendor lock-in. It performs this role remarkably well - the standards are very comprehensive, based on sound engineering practices, managed in a very open way and widely followed with considerable backing from all the major software vendors. It is certainly now true that you can build truly open, standards-based, enterprise-class applications for the J2EE platform. For this reason, many organisations are wisely choosing to standardise on J2EE as the platform for delivering new business critical applications.

Of course, standardising on J2EE for enterprise applications brings with it several challenges.

Typically, enterprise-class applications are expected to have a long lifespan - at least five years and possibly more than 25 years. Because we in the IT sector like 80/20 rules, it's good to remember that over a lifespan like this you can reckon that less than 20 percent of the total cost of developing the application will be incurred in building the application in the first place and the remaining 80 percent of the cost will be incurred during the so called "maintenance" phase. Both business and technology changes drive these lifecycle costs.

In a period of five to 25 years most companies will experience major changes in the business environment either through mergers, acquisitions, changes in competitive landscape, changes in government regulations, advances in technology in their core business areas, development of new products, addition of new sales channels and so on. This means that any business-critical application is likely to require extensive enhancement and change over its lifetime. This really needs to be considered upfront. Too often IT departments attempt to resist these changes and regard them as a threat rather than accepting that the ability to change applications in this way is a core requirement.

On top of the business changes come the technology changes. The J2EE platform is developing at a rapid rate. Applications built to a particular version of the standards will almost certainly need to be adapted to run on new versions of the platform or at the very least to interface to new applications or modules being built to the most recent standards.

So after a few iterations of the business and technology change cycle all those well-intentioned and well-managed efforts to conform to standards will result in a melting pot of application elements built to various standards - the classic maintenance nightmare!

And there's another catch. The J2EE platform brings with it both the Java language, which, however much you might love it, has to be regarded as a third-generation language, and a dauntingly complex array of technologies and standards. There are many choices to make - get them wrong and you'll almost certainly suffer from application performance, scalability and reliability problems. The classic questions of whether to use Entity Beans or DAOs, container managed or bean managed persistency are the simplest examples.

This complexity really limits the ability to find or train experienced and skilled architects, designers and developers who have a good enough understanding of the technology to really make it work. If you can find those J2EE experts then what chance have you got that they can also understand the business requirements for the applications - the number of people worldwide who can really bridge that business-technology gap is tiny. As everybody knows the most expensive changes to a development project come about because the real business requirements were not properly understood in the first place so failure to bridge the gap is expensive!

So overall, in terms of development and maintenance productivity we have taken a considerable step back from the 4GL paradigm. In the current climate where you can count on around 40 percent of a typical organisation's IT budget being spent on staff costs, any initiatives that can improve on that productivity must be welcome.

What's the answer?

IT organisations are looking at many ways to solve or avoid this J2EE productivity issue from all angles - their business model, their organisation, their processes and their tools.

Increasingly organisations are looking at outsourcing application development, both on- and offshore, as a way to reduce costs and manage risks. This is a very valuable tool and should not be overlooked - choose your supplier wisely and remembering the 80/20 rule ensure your supplier will build a well architected, well documented application that can be maintained over its whole lifetime.

Richard Walford is Compuware's product line sales director Asia Pacific region for Uniface and OptimalJ