Tuesday, August 21, 2007

What is software design?

Michael Feathers has a recent blog "It's All Design" where he says:

When I think about what we do in software development, I find it hard to imagine similar things happening in other fields.

He goes on to speculate that an auto designer would never be given a requirement such as there must be fifteen drink holders. I think he's wrong and that we operate in the same way as in many other fields. Come on, there really are vehicles with fifteen cup holders and I can't imagine any auto designer doing that without such a requirement.

In the comments Michael says "I try to imagine what happens in conversations with architects.". Well my wife has a degree in Architecture, but worked in the field only briefly before moving into software development. She has found great parallels between the work in both fields. We are currently working with an architect to design an addition to our house and one of the first things our architect did was ask about any features and requirements we had in mind.

Don't get me wrong, I agree that software development is just one big design process. I really hate how the software development process is so often compared to a manufacturing process. In software the manufacturing is not the development of an application it is copying that application to a disk. What we do, even the lowest level coding, is design not manufacturing.

But I don't agree with Michael Feathers that requirements and design are the same thing:

Maybe requirements is just a word that we use because we're dividing our design work between two groups.. a group that determines the higher level design (what the product will do); and the lower level design (how the product will do it).

Requirements frame design but are the same as design. Something like a performance requirement does not say anything about the design of a product. Software development is a design process and requirements are part of the process, but a stating a requirement is not the same as making a design decision.


Michael Feathers said...

Richard, hi. How do you see them as different if, ultimately, a requirement determines a property of something that you produce?

For instance, if I have a requirement to produce a five-legged chair, isn't five-leggedness part of the design?

Richard Hansen said...

I think we are more in agreement then disagreement and the difference might just be a matter of terminology. It is certainly a fuzzy line separating design and requirements and if you had said features instead of requirements I would be on board. If software development is a design process then requirements and design are just different are pieces of the process, so maybe it is nitpicking, but I don't think the two are equivalent. If they are equivalent are all design features also be requirements? I don't think so, there are certainly different designs that can satisfy the same set of requirements. For me requirements are still about what and design is about how and I think the distinction is useful. Not the distinction of who does what or when it is done, but the distinct focus of purpose for each one. If we blur the distinction too much we could end up with software that is nicely designed but doesn't do anything useful or very functional software that is difficult to use.