His quest is to make writing software as routine -- some might say as boring -- as building bridges or houses. And that runs against the grain of software's traditional maverick culture of lone wolf programmers and a system that prides itself on rebuilding products from the ground up every few years.
Founded in 1984 with funding from the U.S. Defense Dept., the SEI has the explicit goal of improving the practice of software design and development. It includes the CERT Communications Center -- what Cross describes as the "world's help desk for latest virus or cyberattacks." And the SEI administers 10 programs, including robotics, artificial intelligence, and software engineering.
FLY BOY. Cross, now 50, came to software gurudom as a result of serendipity. After graduating from college with a degree in electrical engineering in 1974, he joined the Air Force in hopes of becoming a military pilot. His less-than-perfect eyesight foiled that plan, however, and he ended up designing software for embedded computer systems of the F-15 and F-16 fighter planes. To give him a better understanding of the mechanics of high-performance aircraft, the Air Force ended up letting Cross take wing after all. "I was able to fly in a supervised way and do everything the pilots do. That was pretty exciting," he recalls.
From there, Cross went on to design navigation code for air-launched cruise missiles, build logistics software, and research how artificial intelligence could be used to control air traffic. He has published more than 50 research papers in computing, giving him true spurs as an Ivory Tower geek.
Cross is also a current executive committee member and past chairman of the Information Science & Technology panel at the Defense Advanced Research Projects Agency (DARPA), the respected Defense body that funded projects widely credited with creating the foundation for the Internet. He joined the computer science faculty at CMU in 1994 as principal research scientist in the school's robotics program. Two years later, he ascended to the directorship of the SEI and has since put his experience to work plotting the future of software development.
START WITH A PLAN. According to Cross, that future should have more in common with the nuts-and-bolts fields of manufacturing and construction than with lone coders pulling all-nighters to build elegant new programs. While the latest generation of so-called object-oriented programming languages, such as Java, take a step toward creating these basic components, software development remains far short of standardized.
Moreover, work from one project doesn't necessarily get passed along to the next version of the same project -- even if the initial job was done using an object-oriented language. At the SEI, by contrast, "we always take the example of building a house or building a bridge. You usually start with an architectural plan and do engineering analysis before you build the thing," says Cross.
In most disciplines, 98% of engineering involves following routines, Cross says. Not so in traditional software development. Most projects involve building significant chunks of code from scratch -- and few programmers systematically reuse code. "Everything is a new invention. It's part of the software culture," says Cross. The result can be costly delays and huge cost overruns ?- sometimes doubling or tripling the expected cost of an info-tech project.
GET IT RIGHT. That will change as customers try to hold big software projects to stricter performance standards -- just as the engineers who build a skyscraper are held accountable if the edifice cracks or collapses. Thus far, most customers still accept faulty software, albeit with a lot of complaining. But Cross sees pressure building to get it right the first time -- or else. One or-else possibility, of course, is that customers may use more free software, such as Linux.
Another is that the high cost of reinventing the wheel with every new software project may force companies -- sooner rather than later -- to consider code as an integrated part of a manufacturing process, Cross believes. He cites the car industry as an example. "There are hundreds of thousands of lines of software code used in automobiles, from the logic of air-bag deployment and drivetrains to operating the dashboard console. The amount of code in a car today is incredible," he says.
That's why auto industry supplier Cummins Engine has adopted a centralized and recyclable system to provide all the embedded software it uses in manufacturing. And rather than use a separate set of software to control each of the dozens of engines in its lineup, Cummins has built a single set of code, based on reusable components, that goes into all of its engines.
TRUE UTILITY. For software development to become truly routine, programmers will also have to develop better ways to reuse existing code -- something Cross calls the Holy Grail. Making this approach the norm will require dramatic cultural shifts such as planning projects more thoroughly and setting up processes that enforce development schedules and that audit code during develpment to keep it focused on the project's goal.
Equally as important, claims Cross, will be wider use of open architectures. Both Microsoft and Sun Microsystems are moving in that direction with their .Net and SunOne Web software, respectively. Both products aim to create new applications for consumers and businesses built around common Internet standards. Ultimately, Cross thinks such changes will make software a true utility that's delivered as a service, not as a product. It might be boring, but it will be more reliable -- and more subservient to business goals.
Cross is the first to acknowledge that this idea has suffered from slow adoption so far. Many application service providers that aimed to deliver software over the Internet went bust in the dot-com debacle. But Cross believes that similar companies will resurface and make inroads -- partly because the concept has already been embraced by big players such as Oracle, which now offers an online suite of software tools for small businesses.
ABLE TO ASK. The other Holy Grail of software development for Cross could be simple common sense. Witness the failure of the Mars Rover mission in 2000, where a basic software error caused the lander to crash into the Red Planet. "A third- or fourth-grader would recognize in data going by whether a measurement was in metric or English terms, but that's something the computer on the Mars Rover didn't ask. We will have to build into computers the ability to ask, "Does this really make sense?," says Cross.
That will be no small task in a world where, at the moment, bugs are all too common, and programming means sitting at a computer all night and hacking out code. By Alex Salkever