Sponsored Link •
When Kent Beck and I were playing with Smalltalk, we found it amazing what Smalltalk would do compared to anything either of us had used before. And it really seemed that Smalltalk wanted us to try things. A lot of times, we would just try to see if we knew how to program something. We'd be talking about something, and say, "Gosh. Do you think we could program that?" And we'd just jump in and start programming. And sometimes the programming was almost effortless, as if Smalltalk had been made to write that program. It was amazing. But other times we'd be programming away, and we'd say, "Now, wait a second, what are we working on here?" We'd just get stuck. And if we were stuck more than a minute, I'd stop and say, "Kent, what's the simplest thing that could possibly work?"
It was a question: "Given what we're trying to do now, what is the simplest thing that could possibly work?" In other words, let's focus on the goal. The goal right now is to make this routine do this thing. Let's not worry about what somebody reading the code tomorrow is going to think. Let's not worry about whether it's efficient. Let's not even worry about whether it will work. Let's just write the simplest thing that could possibly work.
Once we had written it, we could look at it. And we'd say, "Oh yeah, now we know
what's going on," because the mere act of writing it organized our thoughts. Maybe it
worked. Maybe it didn't. Maybe we had to code some more. But we had been blocked
from making progress, and now we weren't. We had been thinking about too much at
once, trying to achieve too complicated a goal, trying to code it too well. Maybe we had
been trying to impress our friends with our knowledge of computer science, whatever.
But we decided to try whatever is most simple: to write an
return a constant, use a linear search. We would just write it and see it work. We knew
that once it worked, we'd be in a better position to think of what we really wanted.
So when I asked, "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?" I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more. Our problem is we've got nothing."
I think that that's a breakthrough, because you are always taught to do as much as you can. Always put checks in. Always look for exceptions. Always handle the most general case. Always give the user the best advice. Always print a meaningful error message. Always this. Always that. You have so many things in the background that you're supposed to do, there's no room left to think. I say, forget all that and ask yourself, "What's the simplest thing that could possibly work?"
I think the advice got turned into a command: "Do the simplest thing that could possibly work." That's a little more confusing, because there isn't this notion that as soon as you've done it, we'll evaluate it. People ask, "Well, how do you know it's the simplest?" In my case, we didn't know. We were just going to get it on the screen and look at it. But as soon as it becomes a command, then we have to analyze it and ask, "Is that the simplest?" And all of a sudden it becomes complicated. What is or isn't simple?
There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped. It might just confuse. Sometimes you think, "Gosh, you know, I'm such a wimp, I can't even understand the discussion of simplicity." It scares people.
Coding up the simplest thing that could possibly work is really about this: If you can't keep five things in your head at one time and make a decision, try keeping three things in your head. Try keeping just one thing in your head, and see if you can make a decision. Then you can think of the next thing. And amazingly, when you write some of this dumb, straight-ahead code, it often turns out that it was all that was required. It works great. When a second programmer comes back later and reads the code she might say, "The people who wrote this are morons. They just wrote a simple linear search here. This thing's ordered, so they could have done a binary search. They could have used a hash table here. Why are they doing a linear search?" Well, because a linear search worked. And when the other programmer looked at the linear search, she understood it in a minute.
Come back Monday, January 26 for the next installment of a conversation with C# creator Anders Hejlsberg. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Have an opinion about the design principles presented in this article? Discuss this article in the Articles Forum topic, The Simplest Thing that Could Possibly Work.
Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author
of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java
platform's architecture and internals. His popular columns in JavaWorld magazine covered Java
internals, object-oriented design, and Jini. Bill has been active in the Jini Community since
its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API.
The ServiceUI became the de facto standard way to associate user interfaces to Jini services,
and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected
member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role
helped to define the governance process for the community. He currently devotes most of his energy
to building Artima.com into an ever more useful resource for developers.
Bo Leuf and Ward Cunningham are the authors of The Wiki Way: Quick Collaboration on the Web, which
is available on Amazon.com at:
Portland Pattern Repository:
Information on CRC (Class-Responsibility-Collaboration) Cards:
XProgramming.com - an Extreme Programming Resource:
PLoP, the Pattern Languages of Programming conference: