In-House Innovation

On this side of the Atlantic, a smaller team of developers is using a different approach to build data-rich applications of another kind. The NHL's staff of five programmers uses open-source tools and Java to write applications that let various user constituencies--fans, sports writers, broadcasters, team executives--slice and dice hockey statistics. Grant Nodine, senior director of Web operations for the NHL, says the decision to use open-source tools such as the NetBeans development environment and Cayenne data-modeling framework was only partly a cost-saving move. "I personally have found the open-source tools tend to be better documented and more up-to-date than their commercial counterparts," Nodine says.

Still, the NHL's programmers are under pressure to control costs and increase efficiency. One way they've done that is by creating a common framework of methods and functions that sits between newly developed number-crunching applications and the back-end Oracle database that houses player and game statistics. "We're developing applications in such a way that it significantly reduces the amount of time necessary to manage them," Nodine says.

Detroit Edison, a subsidiary of DTE Energy Co., is taking a different path to software-development efficiency. A few months ago, the utility signed up for a service from TopCoder Inc. that lets it submit work requests to the outsourcing company, which uses thousands of freelance developers located in more than 100 countries. Detroit Edison also gains access to growing catalogs of J2EE and .Net infrastructure components developed by TopCoder programmers. "Prebuilt, pretested components shorten your development time," says Rod Davenport, technology strategist with Detroit Edison, which has its own staff of 300 developers. "This gives us another way to have a greater variety of components and leverage developers at pretty low cost."

In addition to building custom applications, in-house programmers stay busy fine-tuning the commercial enterprise-resource-planning applications used by their companies, integrating it all, and, more recently, introducing Web services to those software environments. When it comes to Web services, Microsoft's Rudder says development managers face a decision: whether to build the Web-services layer themselves or rely on commercial software vendors. Regardless of how they do it, Web services should eventually free software engineers from some of the grunt work and give them more time to spend on business processes.

Such advances are making development staffs at many U.S. companies more productive than ever. New graphical development environments such as Visual Studio .Net and Sun's forthcoming Rave tools also help by automating the way software is developed, creating lines of code with the click of a mouse. "Building applications without actually programming" is one of the hotbeds of activity in development organizations, Sun's Gosling says (see story, Tool Time: Features Boost Developers' Productivity).

But practitioners say there's plenty of room for improvement. "There's still a lot of manually intensive work that goes on in the development process," says AXA Financial's Wollin. Gosling says he encounters Emacs, a 25-year-old bare-bones coding tool, "a lot more than I think is reasonable."

The question of programmer productivity--and the cost of that work--is getting closer scrutiny with the increasing interest in offshore outsourcing. While new languages and tools keep raising the output of U.S. developers, the same products are available to engineers in India, Russia, and other overseas software centers, where upstart companies promise quality code at lower costs. Local developers do have some advantages in working for U.S. companies--day-to-day proximity to the business counts for a lot--but there's no escaping the fact that a growing number of CIOs look at offshore development as a way of lowering costs for at least some projects.

Where does that leave the large base of U.S. developers? For many, the skills required of them may change. Borland's Shelton says U.S. software engineers will have to manage more, develop less. "They're going to be coordinating and controlling quality and making sure requirements are fulfilled rather than writing lines of code," he says. "The lines of code are going to be written somewhere else."

In addition, Gosling says, U.S. developers need to work even harder at understanding user needs, translating business requirements into software solutions, and fitting into the culture of the companies they work for. "You have to be really close in touch with what it is that people want from you," he says.

For developers willing to change with the times, there should be plenty to do. Businesses show no signs of pulling back on the custom software projects that set them apart.