5 Things Grady Booch Has Learned About Complex Software Systems

A handful of über-programmers are immediately recognizable to most software developers, often on a first-name basis—the way that other communities might recognize “Britney” or “Oprah” without further explanation. These individuals shape the way programmers design and build applications, by identifying process improvements or designing life-changing tools.

One unquestioned person on that list is Grady Booch. His primary influence on object-oriented programming was as an original developer of the Unified Modeling Language (UML); he’s also written several influential books, such as Object-Oriented Analysis and Design with Applications. And he’s been chief scientist at Rational (now part of IBM) since its founding in 1980; the most recent formal title is chief scientist for software engineering in IBM Research. Here’s his advice about making big software development projects a success.

1. The fundamentals never go out of style.

Big, long projects can become grim, and in the worst cases they can appear to become a death march. But hyper-productive projects, says Booch, never forget the four fundamentals:

1. Create crisp and resilient abstractions.
2. Maintain a good separation of concerns.
3. Create a balanced distribution of responsibilities.
4. Focus on simplicity.

The key in creating useful abstractions, says Booch, is to use an object-oriented view of the world, rather than an algorithm-based viewpoint. Think about things, he says, instead of processes.

Separation of concerns, says Booch, means, “You don’t put the dishwasher in the bathroom.” The specifics depend on the requirements, but he advises, “Semantically related things should be clustered together and kept separate where they are not.”

Design fundamentals also include avoiding an architecture that’s too “lumpy.” You don’t want to design a house with an enormous kitchen but just one bedroom, for instance.

Don’t underestimate the importance of keeping things simple, he warns—or the difficulty of getting there. “It requires energy to develop simple things,” explains Booch. It’s worth the investment to ensure that every software release includes a step in which developers give attention to simplifying, he says. But it is an investment. Management has to be willing to throw out features even if it cost money to develop them.

2. You need a regular rhythm of releases.

Every project needs a heartbeat, says Booch. “Establishing that rhythm provides predictability and sustainability.” Regularity lets everyone plan on what functionality or features will be injected into the next round, he says, regardless of release frequency.

3. Focus upon growing executable architectures.

IT managers need to govern around the architectural decisions rather than raw, running, naked code. “The code is the truth,” Booch says. “But the code is not the whole truth.”

4. Create social structures that encourage innovation while still preserving predictability.

Teamwork is an essential ingredient in any large software project, so companies should give attention to creating relationships that work. Businesses need predictability (when will this software really ship?) and they also want innovation (make it do something cool!). Building a social structure to support both those goals isn’t necessarily easy, but the successful projects find a balance.

One long-standing point of contention is the degree to which, in those social structures, the manager is a participant in the actual software development process. The architect should also be an implementer, says Booch, even if a line is drawn between development and managers. But there’s a danger of noisy communication when management gets too involved; it’s the difference between a line and a wall.

Another component to creating innovative teams, says Booch, is keeping developers out of “blasted meetings” so they can get things done.

Creating a workable social structure is harder when team members are temporally and geographically dispersed. Booch pointed to IBM’s research project, BlueGrass: Virtual Worlds for Business, which is taking a stab at a solution by providing social interaction for “heads-up” work—mimicking hallway chats and water cooler meetings. The aim, says the BlueGrass site, is to provide people with more visibility into the presence and work of people on the distributed team, and to support brainstorming with simple creation of objects in the world.

His own advice: Get people together in virtual meeting places if you can’t get them together in the same time zone. You need to create places where the opportunity for trust can be created. It should be okay to talk about your dog in the developer chat room, he says; if teams are fostered well, eventually work really will be accomplished.

5. Have fun.

That’s not simply friendly advice; Booch believes that successful projects come from teams that are jazzed about what they’re doing. “Most people want to build beautiful, elegant things,” he says. “If you rob them of that, you’re taking away the passion of the craftsman.”