Found these three great essays by Jack W. Reeves about code as design. The first of these essays has originally been published in the Fall 1992 issue of C++ Journal. The second essay is a follow-up written 13 years later. The third essay is the original letter written to the editor of C++ Journal that then lead to the publication of the first essay.
All that is being said in these essays is still valid today — most notable the core statement: In software development, the design document is a source code listing.
Following are some of the thoughts that popped up while reading the essays.
There is that silly idea in the software engineering community that we have A-level software engineers that create the design (in these days, in the form of UML diagrams). Once the design is completed, an armada of B-level developers then translates the design into C/C++/Java/etc. code. Finally, there are those poor C-level developers (also known as the QA department) writing the test cases. Lying below this is the misconception that programming is some kind of assembly line job, while drawing UML diagrams and writing design documents (and staying away from source code) is actual software engineering. Wrong wrong wrong.
Let's compare this to the way a new aircraft type is created. First, a design is created using various CAD tools. This design is then validated and tested using sophisticated simulation and modeling tools. Once these first tests show promising results, various models are built which are then tested in wind tunnels. Finally, one or more prototypes are built which are then flown by highly experienced test pilots (with a solid understanding of aircraft engineering). The results from test flights can lead to significant changes in the aircraft, causing the engineers literally go back to the drawing board. Finally, after many years and many prototypes (some of them possibly having crashed), assembly-line production of the airplane starts.
So, now imagine for a second what it would be like if airplanes would be created the way we expect software to be built: First, a bunch of highly skilled A-level aerospace engineers draw up an aircraft design using a CAD tool. A bunch of B-level engineers then build a prototype, based on the CAD drawings, which is then test flown by a pilot who has just completed his basic pilot training. Ouch.
Why, then, are we expecting software development to work this way?
Personally, I do not consider a software design finished until I see working code. Testing and debugging is not a sign of a bad engineering in an earlier stage, but an integral part of the design process (in other disciplines, this is called design verification). The same way that test flights are an integral part of creating a new aircraft type.
Posted by guenter at March 21, 2005 01:15 PMThanks for posting this. Reeves brings up an excellent point and it is a surprise to me that it did not receive more attention in all these years. However, his thesis are being confirmed in works of Andrei Alexandrescu - "Modern C++ Design" book (http://www.moderncppdesign.com/book/main.html ) and "The Design is in the Code" paper (http://www.moderncppdesign.com/publications/xp2000.pdf )
Andrei is right on Reeves' track. This is also confirmed by Vlissides' words in mentioned book foreword:
"Andrei's generic components raise the level of abstraction high enough to make C++ begin to look and feel like a design specification language. Unlike dedicated design languages, however, you retain the full expressiveness and familiarity of C++."
And later on:
"Code generators have held comparable promise for years, but my own research and practical experience have convinced me that, in the end, code generation doesn't compare. You have the round-trip problem, the not-enough-code-worth-generating problem, the inflexible-generator problem, the inscrutable-generated-code problem, and of course the I-can't-integrate-the-bloody-generated-code-with-my-own-code problem. Any one of these problems may be a showstopper; together, they make code generation an unlikely solution for most programming challenges."
Furthermore, IMHO, the "code as design" paradigm is in the roots of the open source development model success. This is a puzzle piece that fills in the void (and makes Bill Gates scratch his head ;-) - how can a bunch of people from all ends of the planet boldly skip established and "valid" software engineering design practices and come up with a product boasting industrial robustness? The answer is simple - because they work together on product design and coding is the major and main part of it. Building and testing as many prototypes as one wishes costs next to nothing. An important detail here is that the time investment is driven by true passion, not money.
Posted by: Alex Fabijanic at March 26, 2005 04:29 PM