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
1 comment:
Maybe it's like the relative value of a plan (an artifact) vs. planning (a process). A design created before getting ones hands dirty (coding) has little value (like the plan, its just a guess), but refactoring after traveling many alternate roads is often essential.
Post a Comment