What is software design? – article ideas still ring true 13 years later

Here’s a link to an article by Jack Reeves called “What is Software Design?” from the C++ Journal in 1992.


On source code:


“The final goal of any engineering activity is the some type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team. This is a completely different group with completely different skills from the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build lots of the product, all without any further intervention of the designers. After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.”


On builds:


“There is one consequence of considering code as software design that completely overwhelms all others. It is so important and so obvious that it is a total blind spot for most software organizations. This is the fact that software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free. If source code is a software design, then actually building software is done by compilers and linkers. We often refer to the process of compiling and linking a complete software system as “doing a build”.”


On testing:


“The software design is not complete until it has been coded and tested. Testing is a fundamental part of the design validation and refinement process. The high level structural design is not a complete software design; it is just a structural framework for the detailed design. We have very limited capabilities for rigorously validating a high level design. The detailed design will ultimately influence (or should be allowed to influence) the high level design at least as much as other factors. Refining all the aspects of a design is a process that should be happening throughout the design cycle. If any aspect of the design is frozen out of the refinement process, it is hardly surprising that the final design will be poor or even unworkable.”


On programming languages:


“This says that the collective subconscious of the software industry instinctively knows that improvements in programming techniques and real world programming languages in particular are overwhelmingly more important than anything else in the software business. It also says that programmers are interested in design. When more expressive programming languages become available, software developers will adopt them.”


On development process:


“Also consider how the process of software development is changing. Once upon a time we had the waterfall process. Now we talk of spiral development and rapid prototyping. While such techniques are often justified with terms like “risk abatement” and “shortened product delivery times”, they are really just excuses to start coding earlier in the life cycle. This is good. This allows the build/test cycle to start validating and refining the design earlier. It also means that it is more likely that the software designers that developed the top level design are still around to do the detailed design.”

This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to What is software design? – article ideas still ring true 13 years later

  1. Darrell says:

    Yes, especially the domain model part of the application. Other, technical-only classes can be created, but the domain model should map as closely as possible to the user’s business world.

  2. Greg Postlewait says:

    Love the line "I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings."

    It reinforces the point I often make that source code needs to be readable. Bonus points when its readable enough for non-techies to understands. Good naming conventions based on business logic, not the name of your dog or hungarian notation, is essential.

  3. Darrell says:

    John – yes, very true! It also plays into the dynamic versus static typing debate.

  4. John Bullock says:

    Wow! Some things never change. I would highlight another item from the article:

    "Note that testing is not just concerned with getting the current design correct, it is part of the process of refining the design."

    Sounds like Test Driven Development before it had a name.

    "The choice of algorithms for a given module can be as important to the overall success of the software system as any of the higher level design aspects. There is no hierarchy of importance among the different aspects of a software design. An incorrect design at the lowest module level can be as fatal as a mistake at the highest level. A software design must be complete and correct in all its aspects, or all software builds based on the design will be erroneous."

    I had never really thought about this but it is really very true that a flaw at any point of the design process is as fatal as any other.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>