Wednesday, August 11, 2010

Another excellent quote from the same source...

I propose that the real issue is that design is not really a beneficial activity in software development, and to say "The Source Code Is The Design" is trying to use semantics to gloss over the issue.

I feel this is an important distinction if the goal is to remove the "design" stage from the software development process. Rather than being afraid of being accused of "not doing design", we need to turn the debate around to be "Why should we do design?"

For some tasks, it may be much more cost effective to create a design and evaluate the design before building the actual product. For software, this is not the case. For years, software has struggled to come up with something to use for "design." We had flow charts, PDL, Data Flow Diagrams, prose descriptions, and now UML. With software, however, it takes as much time to create the design as the actual software; the design is more difficult to validate than the actual software; and the simplifying assumptions made in the design are often the critical issues to evaluate in the software. For these reasons, it simply is not cost effective to design, iteratively correct the design, then write the software (and then iteratively correct the software). It is better to start with the software and iteratively correct it.

I believe it is time to explicitly state the long held secret of software, we do not need to do design; design is ineffective and costly. -- WayneMack

From http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign

Best quote ever on software specifications.

Walden Mathews, talking about specifications documents and functional specs and the like, says:

"Specification" is interesting nomenclature, because it's really the lack of specific-ness that keeps it from being the product.

From: http://c2.com/cgi/wiki?TheSourceCodeIsTheProduct, which I got to from http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign.

He's absolutely right. The source code is the first thing specific enough to actually constitute the system—and in a well-written object-oriented system in a high-level language, it’s often just as readable as (if not more readable than) the original “specifications” document.