In some ways, the themes expressed at Gartner's Application Development Summit, held this week in Phoenix, are nothing new. The analysts who are speaking to the audience of CIOs and managers are sincerely trying to help these people create a more productive workforce that is responsive to company needs.

Except, of course, that such events always do have a theme. And while some managers are perfectly capable of grasping the concepts and applying them sensibly, other company bosses bring to mind the phrase, "drinking the Kool-Aid." If your company seems to be in the latter category, belonging to the Silver Bullet of the Month Club in which executives get their latest IT strategy by reading airline magazines, you may wish to be forewarned about the messages that will be brought home next Monday — along with a new set of tschotkes from the exhibit floor.

In their keynote address on Monday, Gartner analysts Dale Veccio and Matt Hoyle focused on four themes: the new application development lifecycle in which the emphasis is delivering applications better and faster (which doesn't sound so new to me); project and portfolio management; "frontier" application development, encompassing Web 2.0; and (with the most fervor) project management and governance.

Developers may be relieved to know that Gartner is not stressing the need for programmers to write code faster. Faster is good, said Hoyle, but better is more important. Hoyle, who refered to RAD (rapid application deployment) as a way to create lousy programs fast, made it clear that agile methods are an accepted part of enterprise software development, and are no longer a subject only for methodology zealots. In his presentation later in the day, "Project Management in a Process Oriented World," for example, Hoyle stressed that task granularity should generally be 8 to 80 hours, and suggested that agile methods be applied to business process management.

But when they say "agile," they may not mean the same thing you do. According to the presentation notes, Veccio and Hoyle say that the keys to unlocking the agility paradox are architecture; a focus on software process and engineering; and reuse — of everything. In the past, they maintain, we've been builders of custom software, or deployers of packages. According to the keynote presenters, in the new, agile application development lifecycle, reuse and assembly are key. "Application development organizations can't code themselves into the future!" they write.

"The future of application development is not about programmer productivity," said Hoyle during the keynote presentation, "but in assembling functionality from components." While programming will not go away, he stressed, programming has decreasing importance in delivering excellence. "Assembling, buying, and extracting is an increasing part of what you need to do," he said. To be more agile and responsive, application development managers have to manipulate, orchestrate, and compose new business processes, using resources available from outside partners, third-party applications, Web services, and existing code components. Veccio asked, "Why would you ever code an app from scratch again? Why would you need to?"

Instead, Gartner is urging managers to consider better process control and governance. Part of that includes the decisions to be made about how companies invest capital in IT, and it also involves choices about the future of existing applications (buy, sell, hold, invest). According to Veccio and Hoyle, "The single most critical issue in designing an application development organization is to clearly understand the functions being performed, the roles and skill sets involved, and the responsibilities that must be lived up to."

Advised Veccio, "Start thinking of governance as an active part of your organization." That doesn't mean that application development teams should adhere to a certain kind of organization (centralized versus decentralized, for instance), but that "the important thing is clarity of role and function." Everyone should know what he is supposed to do and how work will flow through the organization; then managers only have to manage the work flows and the handles.

Next: Kill Projects Early and Often