Sunday, December 10, 2006
What is Software Design?
Conversations at work led me to a question: what does it mean to design software? The software world attaches significant importance design documents. The following Wikipedia quote from their Software design section sums it up:
I went back to my University texts for a definition of design. I read through some of Norman's "The Design of Everyday Things" and scanned a few chapters in Papanek's "Design for the Real World." These got me thinking about the meaning of design outside the software world. I started thinking about a lamp.
What does it mean to design a lamp? You start by understanding the intended use of the new product. You make a few prototypes and test them with typical users to validate that your design will meet their needs. You work within the constraints of the materials and manufacturing processes you have, and you make a plan for how the lamp can be mass produced.
The design process ends with instructions for how an object can be made - that's the design.
What's the equivalent in software development? After a few conversations with my peers, we happened on something interesting: we started with the end and worked backward.
The end of lamp production has a customer pulling a lamp out of a box plugging it in and turning it on. The end of software production then, has a customer installing the software on their computer and using it. That seems reasonable.
Going backward one step, the lamp was built in a factory. The software passed through a factory too, where it was burned onto discs. Again, this lines up well.
Another step back: the factory got the blueprints and manufacturing instructions from the designer and set up their machines accordingly. The software...well, the software arrived at the factory as compiled binaries on a disc.
"Hold the phone," we said.
These binaries are just a direct translation of the code: essentially, we could have handed the code over to the factory. That means the code is the design.
Woah.
The more we talked about this, the more sense it made to me and the more excited I got. In my experience, we learn most about what we're developing while we're developing it. There is clearly a need to have a reasonable starting point, but it's not possible to get it right on paper. That's like thinking that you can fly a 747 because you read the manual.
Saying the code is the design makes sense out of this. From this way of thinking, the 'on paper' design that you start with is the initial design. As the code is written, the design evolves along the path of least resistance, until the requirements are met.
Of course, a quick web search showed this concept isn't new. At all. Here's a seminal 1992 article by Jack Reeves. Read this! It does complete justice to the ideas expressed above.
It is possible to design software in the process of programming, without a planMy organization is fairly typical, and design documents are required. It's important to me, professionally, that the design documents on my projects are as good as they can be. Once I started questioning the nature of design, I discovered that I really didn't have any idea what 'good' means in this context.
or requirement analysis, but [that] would not be considered a professional approach. A separate design prior to programming allows for multidisciplinary
designers and subject matter experts to collaborate with highly-skilled programmers for software that is both useful and technically sound.
I went back to my University texts for a definition of design. I read through some of Norman's "The Design of Everyday Things" and scanned a few chapters in Papanek's "Design for the Real World." These got me thinking about the meaning of design outside the software world. I started thinking about a lamp.
What does it mean to design a lamp? You start by understanding the intended use of the new product. You make a few prototypes and test them with typical users to validate that your design will meet their needs. You work within the constraints of the materials and manufacturing processes you have, and you make a plan for how the lamp can be mass produced.
The design process ends with instructions for how an object can be made - that's the design.
What's the equivalent in software development? After a few conversations with my peers, we happened on something interesting: we started with the end and worked backward.
The end of lamp production has a customer pulling a lamp out of a box plugging it in and turning it on. The end of software production then, has a customer installing the software on their computer and using it. That seems reasonable.
Going backward one step, the lamp was built in a factory. The software passed through a factory too, where it was burned onto discs. Again, this lines up well.
Another step back: the factory got the blueprints and manufacturing instructions from the designer and set up their machines accordingly. The software...well, the software arrived at the factory as compiled binaries on a disc.
"Hold the phone," we said.
These binaries are just a direct translation of the code: essentially, we could have handed the code over to the factory. That means the code is the design.
Woah.
The more we talked about this, the more sense it made to me and the more excited I got. In my experience, we learn most about what we're developing while we're developing it. There is clearly a need to have a reasonable starting point, but it's not possible to get it right on paper. That's like thinking that you can fly a 747 because you read the manual.
Saying the code is the design makes sense out of this. From this way of thinking, the 'on paper' design that you start with is the initial design. As the code is written, the design evolves along the path of least resistance, until the requirements are met.
Of course, a quick web search showed this concept isn't new. At all. Here's a seminal 1992 article by Jack Reeves. Read this! It does complete justice to the ideas expressed above.
# posted by Dana @ 8:50 AM 
