Many have insisted on treating programming like a manufacturing activity. The main reason for the confusion is that TheSourceCodeIsTheProduct is an illusion caused by the expensiveness of producing source code, and the inexpensiveness of compiling executables (ManufacturingIsExpensiveButCompilingIsCheap?).
TheSourceCodeIsTheProduct is an invalid assumption. I think this is the big revelation, which might explain why people shout TheSourceCodeIsTheDesign (when maybe perhaps they should be shouting TheSourceCodeIsNotTheProduct?).
See WhatIsSoftwareDesign, which was the seed that started this page, and which discusses JackReeves' article of the same name.
Maybe if software managers understood better (I could just leave it there ;-) that software product (executables) may indeed be manufactured in any quantity in a short time, flawlessly and cheaply by the machine, they wouldn't try so hard to map all the activities upstream from final build onto a production line.
I guess everyone from FredBrooks on has being saying these things, but MichaelFeathers' comment really crystallized this idea for me.
(If you are a software development manager reading this, be assured I'm talking about someone else.) -- KeithBraithwaite
Since programming is a design activity, not a manufacturing activity, you shouldn't automatically think you can treat programmers like assembly line workers. TheSourceCodeIsTheDesign might help explain why throwing more programmers at a project that is behind schedule will hurt it, not help it. -- francis
A software developer is more akin to an artist than an assembly line worker, since they are designing in writing source code. It takes time, consideration, and in some cases, a bit of skill. Creation can not be rushed. Throwing more people into the design mix can be counterproductive, unless one of them takes the reigns and becomes the architect. More people can be helpful to get the work done, but first you must determine what needs to be done in terms of the design. -- JasonBurkert
The thing about TheSourceCodeIsTheDesign is that it recognizes that coding is part of designing. The difference between someone who can step up to the computer and program/design something well without having elaborately diagrammed it, and a hack who paints himself into corners is really one of experience, talent, and motivation to learn. OK, but what about the LessAbleProgrammer?
The artificial line between programming and design causes tremendous waste. Everyone thinks that software is intrinsically different. That it requires a completely different approach from anything else in engineering. It isn't different, we just misunderstood it. We believed that coding and testing were not part of design. They are just like prototyping on a breadboard. Part of design.
This is one of the TwoIrreparableMistakesOfTheSoftwareField, IMHO. -- MichaelFeathers
Shouldn't the tools be used to extract the diagrams from the source code (I know most tools have this option, but using it is usually frowned upon)? Use Cases may be a problem, but isn't it also a problem when reading source code in determining what end user functions it can perform. Finally, should refactoring show up as cleaner diagrams?
Anyone else care to speculate on how TheSourceCodeIsTheDesign principle could reverse the relationship between UML and source code? [ consider that TheMapIsNotTheTerritory ]
ReverseEngineering is all about this reversed relationship, trying to find out how to distill design representations (potentially UML) from the source code.
If I look very carefully at anything I value, I see a complex chain of effects feeding it. Stable systems quickly become taken for granted, so we place our value tokens on the parts of the changing world that matter. If a design is something other than a product valued for itself, then it is merely some effect that is also a cause in a system stable enough for us to predict a value outcome.
Most computer systems are stable from the compiler down to the execution of binary instructions. Therefore, it's natural to think of "product" as the artifact just above that base. That's language source code. The system that produces that artifact is still quite unpredictable, so it's not likely we'll shift our orientation. Artifacts more abstract, be they whatever, will constitute a nebulous range of "designs" or "specifications". I think it's the lack of a direct and strictly repeatable translation of these artifacts that characterizes them. ("Specification" is interesting nomenclature, because it's really the lack of specific-ness that keeps it from being the product.) Nor is it possible to sort out all the possible forms in this category and give them names.
It seems wrong to say that any one of these tenuously connected artifacts is the design. Unless, of course, it's the only document you have <s>. So, while Reeves has caused me to think in more detail about the chain of effects present in software development, he hasn't convinced me that the source is the design and not the product, practically speaking. But then he didn't claim to have discovered something of practical value, right?
"Advocates ... hold that the definition of a concept specifies its meaning in its entirety. Objectivists hold that the units integrated by the concept constitute its meaning." -- From: http://enlightenment.supersaturated.com/essays/text/ioe1/09.html
-- Hemanth P.S.
Digital systems are highly complex. At their most detailed level, they may consists of millions of elements, i. e., transistors or logic gates. Therefore, for large digital systems, gate-level design is dead. For many decades, logic schematics served as the lingua franca of logic design, but not any more. Today, hardware complexity has grown to such a degree that a schematic with logic gates is almost useless as it shows only a web of connectivity and not the functionality of design. Since the 1970s, Computer engineers and electrical engineers have moved toward hardware description languages (HDLs). The most prominent modern HDLs in industry are Verilog and VHDL. Verilog is the top HDL used by over 10,000 designers at such hardware vendors as Sun Microsystems, Apple Computer and Motorola. Industrial designers like Verilog. It works.
So in chip design, The Source Code Really Is The Design.
Except now Object-Oriented HDLs are coming out such as http://www.aracnet.com/~ptkwt/ruby_stuff/RHDL/ based on Ruby. A UML tool that could generate Ruby could then be used to control the design of the HDL code. So it comes full circle.
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.
See http://www.martinfowler.com/articles/designDead.html for a very different take on the need for design.
A VultureCapitalist isn't going to be interested in SW design documents - source code or reams of dead trees. VCs are interested in whether or not you have a good business plan and business model. Of course, there may be bad VCs that consider themselves able to pass judgement on software specifications, but that's just bad lending practice and has little to do with good engineering practice.
A set of UML designs is not going to convince a VC of anything. Working software is useful, but as the previous writer has noted, the VC wants to see proof that the software can be sold for a profit. Tell a VC that you've gone through your initial capital to create paper diagram of what you want to do and he will probably just walk out the door.
UML diagrams and other associated paperwork (if any) are documentation about the design. A documentation can have different views as appropriate to shed some light (if any) on various aspects of the object described. However, the source code has a privileged status: it is not just "documentation about", it is the object itself.
XP supposedly is about collaboration - SO why is it just about collaborating only with other developers? How do you describe your product to the customer's IT department? The question is more about limiting the artifacts and maintenance of them, and then the communication to other parties that NEED to know... support will not read code, sometimes the deliverables are more than just code, VCs actually do "technical due-diligence" - not just "business due-diligence" - and deciding you know enough about "vulture capitalists" to discount their use of consultants who actually might want to see design - I hope you aren't expecting to woo any investors or market to anyone with technical savvy.
I think too many developers have been ducking the communication skill problem - if you can't present your "design" in meaningful terms to those who would support it, use it, invest in it... you have come up short on the developer skillset. Jobs include the ability to communicate to the business. Knowing which artifacts matter, when and how to use them(minimally - absolutely; not at all - I don't think so!), when informal capture can be enough, what you can reverse out through tools and WHAT YOU CANNOT, how to convey to others, and how not to get bogged down by it... not simply evading that part of the job... comes from experience and collaboration and a predisposition for aggression+quality... that is what we should be talking about.
The binaries are actually the PRIMARY deliverable - not the source - but not necessarily the only one; Also it is not inconceivable that non-code models can be used to generate generate binaries. MDA is way young and perhaps not destined to produce much... but I have worked on projects where, thru code, we took further coding out of the loop! Code that produces code - is a trend - I wouldn't get completely tied to source listings as an excuse for documentation... just be sensible - and not evasive - about reality. If you think you know it all and that things are black and white - you are young.(Even Kent Beck on occasion (paraphrasing) has said you can be too extreme)
You make some nasty assumptions there by saying that the binaries are the primary deliverable, you're wrong. First, it's a mistake to assume there are binaries, you just excluded all the dynamic languages extremeo's love so much. Secondly, you're assuming that the product is where the value lies, but many products are produced for the purpose of being sold, not directly for a particular customer, and often the writers of that code are considering the company itself as the product, hoping to be bought out by a bigger company... who wants that source.
An analogy that came to mind when reading the article was regarding OpenSource. OpenSource is about giving the right to use the design; if you have the tools (which in many cases are FreeSoftware) you can "build the product". A striking difference is what happens when a manufactured good's design is given away. In general, the public cannot use the design to "instantiate" the product without incurring considerably amounts of time/money.
Code as Design: Three Essays by Jack W. Reeves http://www.developerdotstar.com/mag/articles/reeves_design_main.html
Also, for a complementary view look at Component Software by Clemens Szyperski ISBN: 0201745720, there is a very interesting exposition about what is and where the design of a software system resides.
TheFooIsTheBar: TheDesignIsTheSourceCode, TheSourceCodeIsTheSpecification, TheAtomIsTheDesign
More about documentation vs source code: ToNeedComments, SourceCodeAndModeling, TheWhatButNotTheWhy, SelfDocumentingCode, DocumentationBeyondTheSourceCode
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006