How much Design is Enough?

A Quick Comparison

Paul Graham. James Gosling. Whether you like the languages these guys champion or not, I think most people would agree that they’re both pretty good programmers. They also represent two different ends of the programming spectrum. Take the topic of program design, for instance; and by design, I mean spending time thinking about how to write a program before you actually write it. When asked what makes some programmers more productive than others, Gosling responded:

“They think about what they do. They don’t rush in and slap things together. They have a holistic picture of what is to be built.”

Seems like the kind of guy who would be a proponent of designing a program before you start writing it, right? Now, let’s look at what Paul Graham has to say on the subject:

“I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper.”

So, on the one hand, we have the corporate Java programmers who like to work out every detail of a program before they start writing it, and on the other, we have the cowboy Lisp hackers who throw out code and hope for the best. Who’s right?

“We need our design methodologies!”

Allow me to start by saying that I lean more to Gosling’s side. Design is great. I’m wishing I had done more of it sooner.

For example, I’m currently working on a small strategy game. If I hadn’t taken the time to get an idea of how I wanted to write it first, I’d be screwed right around this point. My first problem came in how I wanted to represent the board. Should I just draw sprites in random locations? Should I store the board as a grid of tiles? Ultimately, I went with the tiles. At that point, I had a new problem: in addition to possibly holding a soldier, each tile would also have to have information about its terrain (mountain, forest, etc.).

How would I represent this information? Should I make a list for tiles, have each spot of the list hold an object of Soldier, and have each type of terrain I want derive from Soldier? That’s a bit messy. Should I hard-code terrain information based on the map I load? No, what if terrain changes during battle? If I hadn’t worked out these problems in the beginning, I’d have a mass of broken code.

There’s no need to go overboard on design. Before I started to write my game, I got a good idea of all the features the game would have, what classes and functions I would use in the program, and what all these elements did and how they communicated with each other. That’s all; it was really a very high level overview. But I’m glad I did it; you have to do some design.

Rebuttal from the Lisp Camp

The general sentiment among Lisp programmers who think they don’t need to do design is that the Lisp language gives them this freedom. I don’t really understand the logic behind this, but you can read any of Paul Graham’s essays, or a post on comp.lang.lisp, to find it.

No matter what language you code in, you have to do some amount of design; even in Lisp. When I was writing my RPG language in Lisp, I had trouble in the beginning because I was starting off with a bad design.

My original plan was to read words from a file and look them up in a symbol table to see how the rest of the line would be read. Eventually, I decided to represent rooms in the game as hierarchical data, like XML; I also decided to work backwards, and write the functions to process this data before I worried about constructing it from a file. Seems like a design decision, doesn’t it? If I had thought about my design before I began writing my program, I would have saved myself quite a bit of time.

To Be Continued…

This should probably be called “How much Design is Enough, Part 1”. This game is the first project I’ve ever done any real design on, and I’m very early in the coding process, so I’m going to have to see how it pans out. But so far, this design thing looks like it might be pretty cool. You should do it.

Now, I’ll wait for the angry comments to roll in.

6 Responses to “How much Design is Enough?”

  1. Jeremy Bowers Says:

    You’re supposing a dichotomy where there is a continuum.

  2. Vince P. Says:

    I’m just seconding Jeremy here. You can’t design everything up front in advance. You also can not proceed without any design whatsoever if you hope to be effective. The question of how much design is required depends on the domain, your knowledge of the domain, the implementation context, and your knowledge of the implementation context.

  3. Jimmy Says:

    >You can’t design everything up front in advance. You also can not proceed >without any design whatsoever if you hope to be effective.

    …which was largely the point of my post. “There’s no need to go overboard on design… but you have to do some design”.

    Excellent point on the amount of up-front design being dependent on the problem domain, though; a game will require more design that a script to copy files.

  4. Object Obsessed Programming « Quoted For Truth Says:

    […] my latest project (which I mentioned here), I wanted to do things the OOP Way. Because, as we all know, OOP is awesome. How can it not be? […]

  5. NatPrearf Says:

    This article is about the legal mechanism used to secure property in favor of a creditor. For loans secured by mortgages, such as residential housing loans, see mortgage loan.
    home mortgage online

  6. Object Obsessed Programming (2007) by diamondo25 – HackTech News Says:

    […] my latest project (which I mentioned here), I wanted to do things the OOP Way. Because, as we all know, OOP is awesome. How can it not be? […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: