A Modest Proposal (With Apologies to Swift)

One of the key themes at Java Pro Live! was the need for more integrated tools across the application development lifecycle. Roles are becoming blurred, according to George Paolini, general manager of tools at Borland, so the tools used must be enable the transition from one part of the development lifecycle to another seamlessly. One way of doing this is with a platform that lets you plug in new tools based on the concept of "roles" people assume in the lifecycle. Paolini's goal is to make JBuilder just that platform.

I'm all in favor of more integration between tools across the application development lifecycle. The place where I see it needed is between development and testing. Developers have a continual frustration with the inability to understand and reproduce bugs identified by QA, while the QA testers wish that developers paid more attention to requirements, especially those that stipulate performance and scalability needs. In support of this objective, Paolini demonstrated a feature that enables developers using JBuilder to bring up the requirements from CaliberRM and compare them against working code.

I've always thought that the seamless handoff of an application from one group to the next depended on the easy and natural sharing of information. If operations could provide information to developers that was truly useful in diagnosing a sick application in production, that application would have far less downtime than it does today.

But the idea of tools and information integration across the development lifecycle gives me a more radical thought. Accepted wisdom seems to be hung up on the various roles within the application development lifecycle, and how the individuals filling those roles can work together more closely. That's a worthy goal, but I'm struck by the fact that sharing data still can't hide the fact that those individuals are still separated by common goals.

What do I mean? Everyone wants the application to be successful, but each constituency has a different definition of success. Developers think that a mostly bug-free product using newer technologies to build interesting features is a success. Testers want to ensure those features meet requirements and don't break, while the operations people mostly don't want complaints about errors or poor performance from the users. I realize that it's more complex than that, but I think that most would agree that success across the development phase depends on—at least to some extent—your own role in the process.

My radical solution is to have a single project team design, develop, test, and bring an application to production. The same group designs, builds, tests, and moves the application to the production servers. And even though they might move on to another project at that time, they are still responsible for maintenance and enhancements to the application.

How does this help the problem with tools integration? Integration is trying to solve a problem that was created by the separation and specialization of tasks across the development lifecycle. Eliminate the specialization, and you eliminate the need to integrate tools and share information.

There's a lot in the software development culture working against this concept. It is accepted wisdom that developers shouldn't be responsible for testing their own code (except that many do), because they might unconsciously or consciously not rigorously test in areas they know the code might be weak. But if they are responsible for seeing the application through to production and for fixing any problems that arise with real users, testing might actually become more rigorous.

But you might question whether you can effectively use a multidisciplinary project team at all stages of the lifecycle, or if specialists in, say, software development can be motivated to install and monitor their application on production servers. I would argue that they already do many of these tasks, but from the standpoint of setting up and maintaining the development environment, rather than seeing the application through to production.

And I've always believed that a broader range of skills is better than a narrow one, even if the broader skills are less deep. My friend and colleague Jim Farley (www.eblacksheep.com), who has done just about everything, from system and network architecture to application design and development, would say that he can look up anything that he doesn't know in a matter of minutes, as long as he understands why he needs to know it and how it fits into the solution.

I wonder if that is the type of approach we should be teaching and rewarding, rather than encouraging a depth of specific technical skills. And I think that a single project team with multidisciplinary skills might just be a better solution than getting all of the tools integrated together and sharing information. Tell me what you think.

Posted by Peter Varhol on 10/24/2004