At many companies, programmers are a breed apart. The guys who start work at 11 a.m., keep their office lights dim, and subsist on pizza and Jolt cola might as well, to the average businessperson, be splicing DNA in their cubicles.

But the systems they build--the ones that process insurance claims, design cars, and make sure everyone gets paid--contain plenty of input from rank-and-file managers and engineers who don't live in the world of distributed objects and method calls. And it's exactly that process of translating the workaday requirements of business software into functioning code that's so time-consuming, manual, and error-prone that it's costing businesses big bucks.

To address the problem, several prominent computer-science teams are developing aspect-oriented software-development tools that help manage system-level concerns that cut across classes--or hierarchies or objects--and make code look more like its design. Instead of setting policies by writing scattered code, these tools encapsulate those policies as aspects of a program that can be woven into the code wherever they're needed.

Modern programming languages are designed in a way that's object oriented: Related data and instructions are grouped together in hierarchies of reusable modules that represent entities in a program--say, employees, or products for sale on an E-commerce site. Objects at the top of the hierarchy pass their properties down to objects below, so that, for example, all employees who are managers share certain characteristics. Add a new object, and a lot of the program's knowledge about it gets generated automatically.

Object-oriented systems don't fare as well at encapsulating commands that might touch unrelated areas of the code. So computing-critical policies such as security, error handling, and data caching show up in hundreds or thousands of places scattered throughout a program's code. When business managers ask for changes or updates to a system, all those tangled pieces of code need to be updated. Miss one instance, and the software acquires a bug that can be devilish to find.

"You find systems where people know they're a complete disaster," says James Gosling, a VP at Sun Microsystems who invented the Java programming language in the early '90s. "But when you have a program with a million lines of code, reorganizing things becomes very difficult."

Just as bad, there's no simple way in popular computer languages such as Java and C++ to incorporate into the code the ideas of the nonprogrammers who'll end up using a piece of software. Since much of today's software is embedded in complex pieces of machinery such as cars or airplanes, or is part of complex social systems such as health care, programmers must transform the input of engineers, chemists, doctors, hospital administrators, and other nontechnical specialists into functional code. That, too, exposes systems to bugs.