CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Darrell Norton's Blog [MVP]

Fill in description here...

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.”


Published Feb 17 2005, 11:36 AM by darrell
Filed under:

Comments

TrackBack said:

Software Design hasn't Changed Much
# February 17, 2005 12:58 PM

John Bullock said:

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.

# February 17, 2005 4:14 PM

TrackBack said:

# February 17, 2005 10:32 PM

Darrell said:

John - yes, very true! It also plays into the dynamic versus static typing debate.
# February 18, 2005 7:34 AM

Greg Postlewait said:

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.
# February 22, 2005 7:02 AM

Darrell said:

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.
# February 22, 2005 7:49 AM

TrackBack said:

# March 5, 2005 1:35 PM

TrackBack said:

# March 5, 2005 1:37 PM

Darrell Norton's Blog [MVP] said:

Last time we left off at the XP practices. In the second edition, Kent Beck doubles the original 12 practices...
# May 2, 2005 7:41 AM

Darrell Norton's Blog [MVP] said:

Some people I talk to have struggled with the usefulness of a dynamic language such as IronPython. To...
# June 23, 2005 8:03 AM

Darrell Norton's Blog [MVP] said:

Some people I talk to have struggled with the usefulness of a dynamic language such as IronPython. To...
# June 23, 2005 8:06 AM
Check out Devlicio.us!