The Code Is The Design

danielread writes "In 1992 C++ Journal published an essay by Jack W. Reeves called 'What Is Software Design?' Many credit this essay as being the first published instance of assertions such as 'programming is not about building software; programming is about designing software' and 'it is cheaper and simpler to just build the design and test it than to do anything else'. developer.* Magazine has republished this groundbreaking essay, plus two previously unpublished essays, under the title Code as Design: Three Essays by Jack W. Reeves."

Re:What is Software Design?

[darthpenguin]

If you're curious as to the output of this, it is a raytracer, where you have to catch the output into a ppm file. Here is a jpg of the results [mdek.net], if you don't want to compile and run it yourself.

Re:False Economy

[dubl-u]

But there's no substitute for writing the requirements, feature definitions, scopes and dependencies first, then the comments in the code blocks, then the code, and tar'ing those docs with the source code. The initial hump is steeper, but the total area under the work curve, over the product lifecycle, is much less.

I'd agree that if you're doing waterfall, doing design docs is better than not doing design docs. But I disagree that there's no subsitute.

Having done a few Extreme Programming projects, I much prefer that. Between continuous design, unit testing, acceptance testing, refactoring, and pair programming, I think you get much better code for less money. On a recent project, for example, a 36 developer-month effort released in October and has had a total of two bugs in production and zero downtime.

And the code is in great shape. If a potential investor wanted to send in their technical team for a review, I'd have no fear. Heck, I'm more confident than that: if another team were taking over the code base, I'd happily give them my cell phone number.