In "Application performance management today, part 2: Role of Java developer groups
," hosted on SearchSoftwareQuality, Jack Vaughan has some interesting comments on the (un)changing nature of development and how performance management is affected by process.
Developers tend to spend most of their time maintaining existing applications, rather than actually developing new features. Thus, the glamor of development tends to be a little more workmanlike than we'd like to admit sometimes.
This isn't new information, of course - most developers would admit that new development is fairly rare, and it could be said that even in new projects, with emphasis on agile processes, new features are created as if they were being built in maintenance mode rather than being made out of whole cloth.
Most of the application management lifecycle is spent on finding specific problems, too, even though a lot of tools exist to expose them. (Jack's article mentions a lot of them, and TSS routinely covers them as well.)
Much maintenance can be avoided through two processes, although the SSQ article only mentions one. The first maintenance obstacle can be negotiated through the use of thorough testing (as application failures are a large aspect of application maintenance.)
The other maintenance obstacle - performance - is best managed as an attribute of the code throughout development, instead of deploying an application, testing it, and finding out after "completion" that it doesn't meet its performance requirements.
Agile development helps because it forces more testing throughout the lifecycle; the use of Java application servers also helps isolate performance issues because they provide a central node to monitor. (In fact, many of the performance tools available for Java leverage the application server and its APIs in just this fashion, by monitoring the boundaries between APIs.)
It's an interesting issue. Jack (Vaughan, author of the article), in a private conversation, summarized the piece as saying "Basically, there's no hope. Application developers can and should expect to be chained to their applications forever," despite attempts to the contrary.
What do you think? Is there a way to help developers stay on new development, by reducing the maintenance load?