Contrarian Minds: Rick Cattell

Making and breaking the rules.

By Al Riske

2.Sept.04--Rick Cattell likes to collect and create rules -- about organizations, innovation, and successful products.

Why?

"Good technology is only 10 percent of real-world success," he says.

Cattell's collection of rules -- a book in progress -- is intended to give good technology a better chance. But the unwritten rule seems to be this: Don't let rules stop you.

One of Sun's Distinguished Engineers, Cattell is perhaps best known for a project where one of his own rules was used against him.

"I was a real contrarian in 1996 in saying that Java on the server was going to be important," he recalls, rubbing his sunburned forehead and tousling his already-tousled blond bangs.

"I said that downloading Java apps on the client is going to be nice, but there aren't that many different clients -- just the PC and the Mac and maybe some Unix workstations. So the write-once-run-anywhere thing wasn't as important there as it was on the server, where you had IBM, HP, Sun, DEC, and lots of different companies building lots of different server architectures and different operating systems."

The response from colleagues?

"Basically they used my own argument against me," Cattell says. "Rule 1: Almost all organizations try to do too many things. They said, 'This is too many things if you try to do Java on the server."

Of course, Cattell wasn't about to let his own rule stand in the way of what would become an essential ingredient in nearly all of today's application servers.

To understand Cattell, you have to know where he came from. After earning a doctorate in computer science from Carnegie-Mellon University in 1978 -- his dissertation was on the application of artificial intelligence to software compilers -- Cattell went to work for the famed research lab known as Xerox PARC, where he built one of the world's first client-server databases in 1980.

He describes his seven-year stint there as "the perfect ivory-tower, blank-check research position," but says it wasn't satisfying. PARC became famous for cool ideas but not for turning them into products.

"I wanted to build things that people were going to use," Cattell says.

Sun gave him the opportunity to do that, though he would have to learn some things they don't teach in engineering school.

"I began to realize that there are a lot of ways to fail and only a few ways to succeed," he says. "There are all these steps along the way that you have to do right. You have to understand a real need that the customer has, you have to have a path to get to that customer, you need support from management ... and you have to sell your ideas, which isn't always fun, especially when your audience doesn't agree."

These are the kinds of problems his collection of rules -- many of which sound quite simple -- are meant to address. But things are never quite as simple as we think they should be.

"The rules conflict in the same sense that the laws of physics conflict," Cattell cautions. "There's a law of physics that a body in motion tends to stay in motion, but then there's also the law of gravity. So you can't go on one law alone."

Take, for example, his Rule 40: Committees produce bad designs.

Cattell believes it's essential to have a single architect to steer any given project. "Otherwise you end up with compromises or inconsistencies or lack of coherence," he says.

Worse, if two architects pull in opposite directions, the project may be stretched so thin it finally snaps.

So Cattell put Rule 40 to use in 1996, when he started the Java Enterprise Technologies Group and became the initial architect for what would later be known as the Java 2 Platform, Enterprise Edition.

"J2EE was at risk for design by committee because we involved partners, so I took some ideas that I had learned from my work in the standards area, and said, 'You know, we're going to form an expert group, but one expert will own the specification.'"

It was clearly a contrarian idea, but it worked because Cattell knew when to break his own rule.

"We had a few rough times when the teamwork broke down. For example, Java RMI vs. Java IDL. There was a big debate about which way to go. Basically, the east and west coast teams disagreed," Cattell recalls. "There were people who wanted to use the CORBA standard because it already existed, and there were people who wanted something more natural for Java."

The solution was a compromise -- a way to use Java RMI and talk to CORBA. Cattell had hoped to avoid compromises in the architecture, but, he says, "That's a case where, if the architect had just made a decision, we might have lost half the Java community."

Cattell acknowledges that J2EE has many fathers.

"James Gosling gets credit for Java and to a lesser extent, me for J2EE, when it was actually a team effort," he says. "In computer science today, nobody can do anything by themselves."

Given his desire to create things people will use, Cattell found his work on J2EE particularly gratifying.

"Not only was it something that people would use but it was also getting people in the industry to cooperate -- to stand on each other's shoulders instead of each other's toes."

What's next?

"I have some ideas for innovations Sun could use to change the landscape in database technology," he says.

Which means Rule 29 -- you have to sell your ideas -- will come into play. Again.