The Things I Wish I Learned in Engineering School: A Conversation with Sun Microsystems Distinguished Engineer Rick Cattell

Print-friendly Version

It's no secret that innovative software development often never sees the light of day -- or sees the light of day long after it was created. Rick Cattell, a Sun Microsystems Distinguished Engineer in the Software CTO Group, has been thinking about this problem for some time. After receiving his Ph.D. from Carnegie Mellon University in computer science in 1978, he landed a job at the legendary Xerox PARC, where groundbreaking technology, like the GUI, WYSIWYG word processing, the personal computer, and Ethernet were created, but initially went nowhere.

"Good technology is only 10% of success." - Rick Cattell, Distinguished Engineer, Sun Microsystems

After six years at Xerox PARC, where he developed GUI and database software for early personal computers, he joined Sun in 1984, where he led the database group at Sun developing platform enhancements for database performance, database GUIs, and later CORBA-database integration. He was a founder of SQL Access (a predecessor to ODBC) and the Object Data Management Group (ODMG), co-creator of JDBC, and author of the world's first monograph on object/relational and object databases. His biggest contribution to the Java community was starting the enterprise Java project, which eventually evolved into Java 2 Platform, Enterprise Edition (J2EE). He also contributed to the initial definition of the Java Community Process (JCP).

The author or co-author of some six books on data management and Java technology, and dozens of articles, Cattell is currently writing a book, tentatively titled "Things I Wish I'd Learned in Engineering School" that he has presented in talks at universities around the US. We met with him to learn about pitfalls that developers should avoid.

As a mover and shaker in the creation of J2EE, you encountered a lot of resistance at Sun when you said that Java technology on the server would be important. What did you take away from that experience?

I encountered resistance because the management didn't want do too many things. That is my own rule #1 -- organizations fail when they try to do too much. I needed to convince Sun management that it was important to fund a platform for Java technology on the server. That is also one of my rules: you have to sell your ideas. With help from my colleagues, I convinced management by showing them the support for the idea from customers and partners.

There was a shared fear that the domination of one company on the client side would spread to the server. Partners like IBM, Oracle, and BEA rallied to the cause of a common platform for Java technology on the server.

I also looked at the logic of the players. When you looked at Java technology on the client, there were only a few platforms that mattered, like Windows, UNIX, and Apple. But when you look at Java technology on the server, including the hardware, the operating system, the application server and web server platforms, there were a lot of platforms. And it seemed to me that the value of Write Once, Run Anywhere would really take off on the server side, because it was important there.

The predecessor to the Java Community Process (JCP) was very helpful as well. When I joined JavaSoft, Sun's original Java technology organization, in the summer of 1995, I started working on JDBC -- Java Database Connectivity. I was surprised at how cooperative everyone in the industry was, and how effectively I was able to work with them in what we would now call an expert group. The work on JDBC went five times faster than any standards activity I've ever been involved in, and the results looked less like it was designed by a committee. I wrote up a document on my experience with JDBC for the management and my colleagues in JavaSoft, which, after many iterations, became a predecessor to the JCP document on how to effectively organize an expert group to reach adequate consensus. If you look for perfect consensus, you usually end up with a design by committee. With a strong specification lead, you can get a coherent design and still retain a high degree of consensus.

Why?

I think it's because the specification lead has a little more than an equal vote. The specification lead acts as an architect, not simply a secretary recording a long list of disjointed proposals and votes.

Things I Wish I Learned in Engineering School

You have been giving a talk for some time titled "Things I Wish I Learned in Engineering School," and are writing a book about it. Let's imagine that you are back in 1978, and you've just received your Ph.D. in computer science, and are entering the labor force. If you knew everything then that you know now, what different choices might you have made in your career? What red flags would you have recognized as warning signs at different points? And how might it have led to different outcomes?

First, I didn't realize how important it was, for me at least, to work on things that people are actually going to use. I didn't realize that it wasn't very satisfying to write research papers or even to build working systems if the results of my labor weren't going to be used in the real world. That is probably the overall theme of my book -- if you want to see your ideas used in the real world, you have to think about more than just the engineering.

I also didn't realize that good technology is only 10% of success. If your management doesn't know how to manage a successful engineering project, or your marketing department doesn't know how to access the customers, or doesn't tell you what the customer wants, or if your lawyers don't handle your intellectual property correctly, or if the chief architect doesn't have the ability to create a consistent and simple architecture, then your work can be for naught, and you can spend years building things that never see the light of day.

How important is luck?

A lot of people will call it luck, but I actually think that it's possible to succeed based on principles. For example, people would say it's luck that Google or Sun or Amazon were in the right place at the right time. With some thought, you can understand how to be in the right place at the right time. I've learned that it's more than luck: there's some method to the madness.

When you talk about succeeding based on principles, what do you mean?

I'm thinking of the kind of principles that are in my book: Understand what the customer wants. Realize when a paradigm shift is happening, and take advantage of that. Look for a leader who understands not just the technology, but the market and management.

How can software engineers best know what their customers want?

It helps if every engineer talks to customers occasionally, not just the marketing guys or the senior architects.

Doing Too Much

Your #1 rule is that organizations try to do too many things. How do we know what's too much? Are there any red flags that appear? And who in the organization is in the best position to determine this?

The rule about trying to do too many things can be applied at every level of the organization. For example, at Sun, we can be doing too many things as a company, or too many things in software. Or we could be trying to do too many things in the operating system, or in one particular part of the operating system. So, I think everyone at every level should focus on what they can do well. And organizations as a whole should do the same.

How do you know you're doing too many things? I would say: Make a list. Set your priorities. Set goals. See if you're set up to succeed at those goals. And if not, figure out how to focus on a smaller set of priorities. You can do that as an individual. That same technique can be applied at every level of the organization. The biggest red flag is missing your goals.

Being First Versus Being Best

You argue that developers often don't understand that being first is more important than being best. You point to Classic Coke, Bayer aspirin, and Tylenol as examples. What are the best examples in software?

UNIX spread by being the first "open source" operating system -- "open source" meaning that the source was widely available and cooperatively enhanced. Note that UNIX succeeded even though there were better operating systems in terms of architecture and innovation. It succeeded because it was first as open source.

"With some thought, you can understand how to be in the right place at the right time." - Rick Cattell, Distinguished Engineer, Sun Microsystems

There has also been a "home field advantage" for the early programming languages, despite the introduction of many better ones over the years. FORTRAN was the first high-level programming language. COBOL was the first widely-available business programming language. C was the first widely-available language for system programming. All of these languages are still around, despite their drawbacks. The Java platform became popular because it was the first in a new category: platform-independent programming for the Internet. Lots of other programming languages in the last 40 years failed because they were not "first" in a category, even though they were really good languages.

In fact, I was personally frustrated in the early '90s that the best programming languages were never very popular. I jumped at the opportunity to join JavaSoft because I felt the Java language was in the right place at the right time. It had the potential to be a good programming language and a popular programming language. It's no fun chasing memory leaks and memory clobbers in C and C++. I believe programmers are more productive (and have more fun!) in the Java environment.

Some might call it "luck" that the Java language rode the Internet wave. I would call it good recognition of the rules for success. Of course, being first doesn't guarantee success for a technology. You have to consider the other rules as well: a technology needs to be "good enough," and it needs a distribution channel to a large audience. You can find more discussion of the "first is more important than best" idea in 22 Immutable Laws of Marketing, by Reis and Trout.

I would assume that many software engineers are not fond of the idea that it's more important to be first than best.

There's a lot of resistance to the idea. As engineers, we're taught the reverse -- the engineering field is about good technology. It's not about getting it out to customers or financial success. So, if you want to be a good engineer, you build good technology. What I'm saying is that, as a person looking for personal satisfaction, you may find it important to look beyond the engineering, because your success in the world will involve more than just successful engineering.

Signs of Failure

You point out that there are a lot of ways to fail, but only a few ways to succeed. What are some warning signs of failure?

Developers are often in an awkward position because they're putting their trust in management. They're building some piece of a solution, but they're not personally responsible for getting it to customers, or even understanding what the customers want. Developers may want to look at the track record of their leader. One warning sign would be if your leader has never succeeded before. Another would be that you don't feel connected to your customer -- you don't think you know what your customer really wants. Perhaps you've never talked to them and you're being told that they want.

If you find yourself in a start-up, and you're concerned that the company may be failing, then you have a hard choice of whether you're going to be the last one to turn out the lights, or if you're going to abandon ship. You have to step back and understand whether the new round of funding is going to rescue you or not.

"One warning sign would be if your leader has never succeeded before. Another would be that you don't feel connected to your customer." - Rick Cattell, Distinguished Engineer, Sun Microsystems

I probably evaluated between 100 to 200 start-ups applying to Sun for venture capital in 2001 and 2002. In nine out of ten cases, it was evident that they were making some big mistakes -- they did not understand who their customer was, or they did not understand how to manage a successful engineering project, or their product lacked architectural consistency. The architecture was produced by ten people, and it looked like it was produced by ten people.

Lessons from Xerox PARC

You worked at the legendary Xerox PARC from '78 to '84. They were on to a lot of great things like the GUI, but no one knew how to market them. What are the lessons of Xerox PARC?

There are several reasons why Xerox PARC failed to get some real customers. One was that Xerox was not a company that knew how to sell computers. Their sales force and management didn't understand that market. Another was that we, at Xerox PARC, focused on the technology without understanding how to deliver it to customers -- for example, it cost more than $10,000 to build a personal computer like the ones that we had. Steve Jobs figured out how to make a personal computer almost as good, the Mac, for far less money. So, we were not focusing on the price and the packaging. We focused only on the technology.

Inconsistent Rules

In presenting rules, a lot of people often include a rule that invites you to reject all the rules if they don't apply in a particular context. George Orwell has rules for writing, and his last rule is to break any of his rules rather than writing anything atrocious. Do you have any rule like, "Break any rule if it makes sense to do so"?

The way I would say it is: You have to think about all the rules, not just one or two. So, for example, in physics, you have to think about gravity and electromagnetism and the laws of motion, and the net effect you're going to get is a combination of all of those forces. In the same way, there are a lot of rules for doing successful engineering in business. You have to think about the gestalt, the combination of the rules, and not get fixated on being first to market or having the best technologies.

Any final comments?

I encourage developers to go to http://cattell.net/book.htm and take a look at the slides and the pointers to talks at universities. I'm also interested in hearing about inspired software projects that failed, so feel free to email me at rick.cattell@sun.com. I'll credit anything I use in my book.

See Also

Rick Cattell's Lessons
Rick Cattell's Home Page
Java 2 Platform, Enterprise Edition (J2EE)
22 Immutable Laws of Marketing
The Poetry of Programming
The Next Move in Programming: A Conversation with Sun's Victoria Livschitz