The design of design, part 1

Posted by: stak
Tags: design, books
Posted on: 2011-01-02 20:55:13

I recently read The Design of Design - a book by Fred Brooks (he of the MMM). It was pretty interesting, and I would recommend it to any designers in the computer industry. Although Brooks tries to abstract out the design concepts from being tied to specific domains, a lot of the examples he uses are from software/hardware, so people working in other domains might find it harder to follow. There are also some case studies near the end of the book which also look at design projects in other domains, such as home renovations, book writing, etc., but I found the case studies to not be all that useful to begin with. Anyway, as I was reading I had some thoughts about stuff he said. This is the first in a series of posts on this topic.

(Warning: this post turned out to be more rambling than I expected, since I didn't really have a clear point to make. But composing this post helped me think about this stuff more clearly, so I'm going to post it anyway instead of just deleting it.)

In Chapter 4, he talks about how, because of imperfect communication and human "sins", we need to create contracts that identify the deliverables and lock down requirements and constraints. In software, the problem is usually that the contracts are created too early, before a full understanding of the project and its design can be reached. This is partly because with software, it's often hard to tell where the design stops and the implementation starts. However, when I think about my own experiences, I've noticed there's usually a point where I know I've hammered out all the unknowns for a particular component - I have a fairly concrete idea of what I need to do, what data structures and algorithms I'm going to use, and the overall architecture of the code that I'm working on. Although I haven't considered all the details, and resolving those details may affect the component architecture I have in mind, it's highly unlikely that those details will cause a change in the overall design of the project. This is the point where I would consider the "design" done.

The problem is that this point occurs pretty late in the project. For one thing, I tend to favor top-down designs and work on components sequentially. Within each component, I would estimate that the "design is done" point occurs after 60%-70% of the total time I spend on the component. So if I have a project with four equal-sized components, with my usual programming style, I would only be finished with all the design work after completely finishing the first three components and finishing ~65% of the work on the fourth component. This would put me at ~91% done for the whole project. Even if I shifted things around and did all the design work for the components first, it would still take me 60%-70% of the total time spent on the project just to complete the design.

Now if the project is something that I'm doing for my own needs, then this isn't a problem. But in industry, the design might be one of the factors used in coming up with an time/cost estimate for the whole project. Taking ~65% of the total time to provide this estimate is a little unreasonable. But if that's how long it takes to do the design, then that's how long it takes, and I can't think of a way around that. The other option to reduce the estimation time is to find other ways to come up with an estimate - ways that don't require a full design of the project. This is what often happens in industry now - estimates are created based on the amount of time it took for previous projects of similar scope. What I'm afraid of is that by using alternate estimation techniques, people might think there's no longer a need to do any design work* at all, and go straight to haphazardly attempting an implementation which will be poorly designed.

* In this context, I'm using a specific meaning of the word "design" from the book - an interactive process that is used more for helping the customer discover the requirements than for helping the developer determine an implementation strategy. I guess this could largely be called "requirements elicitation" instead of "design work", but the former term doesn't cover everything the latter implies.

[ Add a new comment ]