Forgot your password?
typodupeerror
Programming IT Technology

The Code Is The Design 354

Posted by Zonk
from the design-is-law dept.
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."
This discussion has been archived. No new comments can be posted.

The Code Is The Design

Comments Filter:
  • Oh Boy. (Score:5, Funny)

    by Anonymous Coward on Tuesday March 01, 2005 @05:37PM (#11817476)
    Here we go.

    The UML monkeys are gonna have a fit!

    • Re:Oh Boy. (Score:5, Insightful)

      by museumpeace (735109) on Tuesday March 01, 2005 @06:22PM (#11817931) Journal
      You are trolling but there are much better educated responses than your taunt deserves.
      Well, I am no UML monkey and I have seen software development process overdone so badly even the lowliest coder had rigor mortis. But let me share a few experiences that may be exceptional but I doubt it.
      1. I have actually worked with a programmer-turned-project-lead who often stated exactly the premise of TFA as a defense of his designs. He also used design reviews and other people's UML as target practice for a particularly nasty and apparently insecure dismissiveness. He was one of the most brilliant coders I ever met. He understood many programming principles better than others but had a pathological aversion to sharing insight. He was utter hell to work with, poison for the work and the workers in the team. His designs ultimately foundered when noone but him could extend or maintain them.
      2. Though language and architecture are not completely seperable, its a shitty design that can't be expressed in any thing but some particular language...saying UML or flowcharts or whatever gets in your way is just a huge hint that you don't know how to express your idea or you don't really have an idea.
      3. There is not much argument about the proclivities of programmers: they don't read other peoples code, not often enough, not with sufficient comprehension, not unless they are paid to maintain it. That is a generalization of course but with way too few exceptions. Comments, as others will surely point out, are more important for the longevity of code than the code itself. But commenting that can stand in for requirements and specifications? Virtually nonexistent, there is less of that than there is of good UML. I have been to the long, expensive funerals of way too many programs and sometimes, the companies that were built upon those programs to have much respect for an aproach to software that de-emphasises visibility of the big ideas and critical commonalities in code. Those are aspects that good design documents capture. Those are what make real software, software that can be changed by someone other than the author, software that can be quickly re-tooled for another market or a new platform, hang around long enough to make a company some money.
      I'd say the great failing of UML or other design languages or symbology is only that it is not tied to code in such a way that code changes back-propagate to the design document. Its just plain hard work to keep design and code on the same page [litterally and figuratively] but that's what you would pay a competant programmer to do. And that's why JavaDoc and its ilk are my preferred solution in this area[ but I can't point you to a solution that completes the higher level documentation job.]
      • Re:Oh Boy. (Score:5, Funny)

        by jacquesm (154384) <j @ w w .com> on Tuesday March 01, 2005 @06:32PM (#11818040) Homepage
        in the good old days code unreadability was directly proportional to job security :)
      • Re:Oh Boy. (Score:3, Insightful)

        by jallen02 (124384)
        Not such a brilliant coder then ehh?

        The best way I have ever heard someone explain how you can tell of an interface is good is if you look at it and think, "Of course. How else would you do it?". The design is natural and flows well for your average *skilled* programmer. If someone is very taltented but no one else can understand their designs then the code is not maintainable. Code that is not maintainable is not good. Creating unmaintainable code is something BAD programmers do. So you should consider th
      • Re:Oh Boy. (Score:3, Insightful)

        by Doomdark (136619)
        I'd say the great failing of UML or other design languages or symbology is only that it is not tied to code in such a way that code changes back-propagate to the design document. Its just plain hard work to keep design and code on the same page

        And I maintain that UML is to programmers what bicycles are to fish...

      • Re:Oh Boy. (Score:4, Insightful)

        by timeOday (582209) on Tuesday March 01, 2005 @09:11PM (#11819615)
        I'd say the great failing of UML or other design languages or symbology is only that it is not tied to code in such a way that code changes back-propagate to the design document.
        Well, Rational had (has?) their idea of "round-trip design," which in practice meant you could generate diagrams from code.

        We never found that useful, but what we did do was generate all header and implementation files from the diagrams. To change the class, you changed the diagram and regenrated the files. This way ensured the diagrams accurately reflected the static interdependecies among classes. All the real logic was in the code blocks, of course, which the tool simply copied verbatim from version to version.

        Was it useful? I guess so. I'm not sure it was more useful than the same information extracted into in a textual document more like Javadoc though.

        Anyways, yeah, you need requirements and specifications too. But don't forget those requirements and specifications are just as buggy as code that's never been compiled or run, because that's exactly what they are - very high level pseudocode, that can't be subjected to the rigor of execution in themselves.

      • I can visualize lots of code/processes as UML type
        diagrams, but I see spending 4hrs drawing some crap as a waste when I could have completed the code by then.

        I tend to write my code as nice as possible that even a drunk coder could understand it.

        I may code up stuff fast with out UML diags, but if people/others need to maintain it, doing a high level UML or layout diag is easy enough to do on demand. Somethings are sometimes too easy to comprehend so id rather not waste hours doing fancy diagrams putting m
  • I'll Add... (Score:4, Insightful)

    by Sexy Commando (612371) on Tuesday March 01, 2005 @05:38PM (#11817483) Journal
    The code is the comments.
    • Re:I'll Add... (Score:2, Insightful)

      by Inkieminstrel (812132)
      In that case the code is misleading.
    • by agm (467017) * on Tuesday March 01, 2005 @05:57PM (#11817691)
      Hey, it was hard to write, it should be hard to read!
    • Re:I'll Add... (Score:2, Insightful)

      by Ohrion (814105)
      "The code is the comments." This actually only works when both the author as well as the maintainer(s) are good coders. Unfortunately in the real world, this usually isn't the case. I've read some really crap code with GoTos all over the place where the author didn't put comments in, and the names of the procedures were all similar to "DoWork". Therefore I try to promote the use of comments in our work, especially if anything gets complex or uses non-obvious APIs.
      • Re:I'll Add... (Score:5, Insightful)

        by DunbarTheInept (764) on Tuesday March 01, 2005 @06:27PM (#11818000) Homepage
        That doesn't fix anything because in general I have observed that the same author who would write impossible to understand code will also write impossible to understand comments that actually mislead you more often than they help you. People who are bad at explaining a precise algorithm's details in an elegant form using Java, C, Perl, or Python are also bad at explaining it in an elegant form using English, for the exact same reasons. They're just not good at communicating carefully and clearly in general.

      • Re:I'll Add... (Score:4, Interesting)

        by chris_mahan (256577) <chris.mahan@gmail.com> on Tuesday March 01, 2005 @06:32PM (#11818042) Homepage
        It's like english. You know, the annotated book because the author really went all out and the reader has no fucking clue:

        Ye whimsical faerie of yore
        Whence came thee upon me?
        Forlorn sit I stilled,
        Prey to thy designs.

        Now, the author wrote about his helplessness at dealing with his past.

        Just because you can't understand what he said does not mean he should not have said it.
        Perhaps it is the skill of the reader that must rise to match that of the author?

        Perhaps it should be rewritten like this:

        Memories from a hidden place make me sad?

        Still too poetic, less descriptive?

        How about: I am saddened by a memory.

        You can make good code go bad by writing for the least common denominator in your organization (always the worst programmers)

        Managers: You can raise code quality by letting go your bad coders. Not because they won't be writing bad code, but because the other coders will be able to write more powerful code.

    • Re:I'll Add... (Score:3, Interesting)

      by Ann Coulter (614889)
      Add to this the fact that comments are never compiled and you can say that comments can be anything related to the executed instructions besides the instructions themselves. That being said, it is very important to let developers (yourself, coworkers, and future developers) of the code have the ideas you had when you were writing the original code in the first place.

      An extreme extension of your statement would be that the instructions for the machine have less gravity than the instructions for the devel

    • Re:I'll Add... (Score:5, Interesting)

      by DunbarTheInept (764) on Tuesday March 01, 2005 @06:34PM (#11818058) Homepage
      In general, when I'm using a language with embedded documentation features (like Java's javadoc, or "doc++" that does exactly the same thing for C++ comments), I prefer to write the specs using the embedded doc tool itself (write out the spec for a java class by writing out the methods as do-nothing stub routines and then describe what they will do by prepending a javadoc comment to them - then when you generate your javadocs, you have the spec - and since they render into HTML, you can actually make the specs with a lot of complex formatting and all that, just the way the bosses like it. Thus my spec is also the skeleton of the code to be filled in. This approach works better, I think, because it makes it easier to keep the spec up to date when you discover a problem during the coding phase that requires a spec change.

      Alas, of late I've been dealing with stuff that doesn't have embedded comment docs and so I haven't been able to do that as much.

    • Don't ask me why, but I like this page. :-)

      Debug only code - comments can lie. [javaranch.com]

    • Re:I'll Add... (Score:3, Insightful)

      by ShieldW0lf (601553)
      If your design is good, the code tells you what it does better than comments.

      Comments shouldn't be telling you what the code is doing, they should tell you why it's doing it.

  • boiler plates (Score:2, Insightful)

    by BBrown (70466)
    sigh. I hope this reads better than the headers and comments I normally struggle through when trying to understand another coder's thoughts.

    • Re:boiler plates (Score:4, Insightful)

      by mccalli (323026) on Tuesday March 01, 2005 @05:50PM (#11817617) Homepage
      I hope this reads better than the headers and comments I normally struggle through when trying to understand another coder's thoughts.

      Fair enough, but would that same programmer have produced a decent design anyway? UML, pseudo-code, anything?

      In my opinion if their code is disorganised, their design would be too.

      Cheers,
      Ian

    • Re:boiler plates (Score:5, Insightful)

      by Rei (128717) on Tuesday March 01, 2005 @06:16PM (#11817875) Homepage
      Part of the problem with headers and comments is the exact same problem with pseudocode: they're not maintained. If they're wrong, the code program doesn't break. The longer they sit around, the less likely they are to be accurate. That's why self-documenting code is a lot more important. Simple, straightforward functions, long, descriptive variable names and functions, etc. If you have to comment a "section" of a function call with a relatively short but important comment, why not just break that part out into its own function call with a descriptive name similar to the comment that you'd use? It's not like the program will run slower; modern compilers can choose whether to inline functions or not better than programmers can in most cases.
  • by fembots (753724) on Tuesday March 01, 2005 @05:41PM (#11817505) Homepage
    Might be timely to revisit
    Six Laws of the New Software [slashdot.org]
  • by Anonymous Coward
    Given sufficiently high level languages (as appropriate for the app) this would be true.

    While we are at it, the comments are not needed either (there should be a compiler warning for them).

    (not completely joking)

    In practice languages are too low level no matter what you use or have "leaky abstractions" which cause problems.
    • The wait for a sufficiently high level language is probably as fruitless as hoping for a system which understands "hey computer I'm sure you can figure out what I want, so just do it".

      In the "old days" we had architecture, design and coding. For all the UMLs, extreme programming, etc. we essentially have these.

    • "(there should be a compiler warning for them).

      (not completely joking)"

      I'd go a step further and throw a semantic error if suffeciant comment's were not found before certain constructs. Hell, make them part of the language. Or, at least provide an easier interface for programmers to document their code in a way similar to how many DVD's have the directories commentary attached...
    • In reality the sequence always goes:

      requirements - design - implementation

      If you subsume the design into the implementation, then someone who goes looking at the implementation will have no way to distinguish between what was a design decision from what should be relatively arbitrary implementation decisions.

      Why is the distinction important? Two reasons, really. One is versatility. You don't want to constrain a design to having just one implementation. It's useful to be able to choose among com

    • Given sufficiently high level languages (as appropriate for the app) this would be true.

      And God said, "Let There Be Light."

      God uses a very high level language: four words, and the hard work is done.

      -kgj
  • by Anonymous Coward on Tuesday March 01, 2005 @05:43PM (#11817536)
    developer.* Magazine has republished this groundbreaking essay, plus two previously unpublished essays, under the title Code as Design: Three Essays by Jack W. Reeves."

    I'm supposed to be impressed by this? Ten years to republish an article? What a rag. Why, here on Slashdot, you barely have to wait te--

    [sound of post getting modded into oblivion]
  • by Anonymous Coward
    Is his thesis useful, actionable in a way that is substantially different than what people were/are doing already?
    • by Ungrounded Lightning (62228) on Tuesday March 01, 2005 @06:38PM (#11818092) Journal
      The article title is misleading.

      It makes it sound like he's talking about coding with no forethought and eschewing all documentation (including all comments) in favor of letting the code be the documentation (the "self-documenting code" falacy that has been touted - and known to be false - since at least the early '70s).

      What he's actually arguing is that the steps of the process are misnamed - and that this results in mismanagement. The documents currently called the "design" are just requirements and a high-level / overview documentation of early thoughts. The process currently called "coding" is actually most of the design work.

      This is recognized in the silicon industry - where CAD tools have evolved the process of "designing a chip" into something virtually identical to "writing an application". But in the silicon industry the nomenclature is still "designers" for "programmers" - and "verification-" or "design assurance-" engineers for "test engineers".

      (The latter, by the way, is a highly skilled specialist {in either software or hardware operations} that many software shops don't use, substituting "testers", or confusing them with testers when they happen to have gotten one by mistake. On the "hard side of the force" such people are normally recognized as high-status (and high-pay) pros - the architect's police force and the designers' respected teammates and designated rescuers.)
  • False Economy (Score:5, Insightful)

    by Doc Ruby (173196) on Tuesday March 01, 2005 @05:45PM (#11817549) Homepage Journal
    It's cheaper and simpler for the initial programmer. After that, we have to spend time (and therefore money) decoding the original code, recognizing idiosyncracies, and retrofitting to work with other code. Even if it's the same programmer, a couple of years later. C++ is more "self documenting" than most languages, when coded properly. And it certainly seemed like the remedy to C, back in 1992 when that screed was written, and C++ was just beginning to be adopted by mainstream programmers. 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.
    • Re:False Economy (Score:5, Insightful)

      by nagora (177841) on Tuesday March 01, 2005 @05:51PM (#11817624)
      C++ is more "self documenting" than most languages, when coded properly.

      That's what they all say. Every language is self documenting when "coded properly". C++ failed in part because of the unfounded belief that its supporters had in its abilities, all of which resided not in the language itself but in the programmer's ability to "code properly". Sadly, there is nothing in the language to enforce such coding practice and it is as rare in C++ as any language.

      TWW

      • And probably impossible to do anyway. Things like good variable and function names would take an AI capable of passing a turing test to check.
        • yea i got that working last week, then my boss made me have it look at its own source code. the thing hasn't been sane since.
      • Actually, of the dozens of languages I know, going back to vintage 1977 BASIC, and extending from 6502 assembly through VB to JavaScript, C++ *is* the most self documenting. Lots of patterns are codified in its structure. Lots of structures among its code are explicit in its operators. There's a big difference between proper encapsulation and fake OOD - which is immediately apparent. C++ is *more* self documenting, but not enough. Hence the entire thrust of my post. FWIW, I might someday be satisfied with a
        • obligatory request: can you provide examples? because I can see no self documenting features in C++.
          • Re:False Economy (Score:3, Insightful)

            by Javagator (679604)
            I would not call C++ exceptionally self documenting, but well written C++ can be very elegant. There is a chapter in Meyers Effective C++ titled, "Say what you mean and mean what you say." My copy is at work, but he mentions that the use of const, virtual functions, abstract functions, and other constructs can reflect design decisions. Also, the proper use of constructors and destructors can ensure that objects are always initialized properly, that an object stays valid over its life time, and releases i
            • Re:False Economy (Score:3, Insightful)

              by deadlinegrunt (520160)
              "... he mentions that the use of const, virtual functions, abstract functions, and other constructs can reflect design decisions"

              The nexus here is the inability of people to agree on a level of competency to understand how true Meyers, and your post, are. C++ is not only capable of showing what the code does (duh, it has to) but also reflecting design decisions. The only reason I can understand the people that do not accept this is because of limited understanding or total lack of it.

              Given its "hardcore
      • C++ failed in part because of the unfounded belief that its supporters had in its abilities

        I must have missed the memo that C++ had "failed". I'd call being one of the most popular languages around, still a major part of the software industry some two decades after its introduction, one of the bigger success stories in software development history.

        As for belief in its abilities: the problem C++ has is more PR than anything else. A lot of people learned it ten years ago, or were taught by or learned fr

        • Re:False Economy (Score:3, Interesting)

          by nagora (177841)
          I must have missed the memo that C++ had "failed".

          In the sense that it made no real difference. The programming world today is largely the way it is because of C, not C++. If C++ had never happened, but C, Smalltalk and Simula etc. still had happened, then I don't think there would be any noticable difference in modern programming style or technique, not even much difference in syntax. I think, anyway.

          Obviously, C++ programmers might not agree!

          TWW

      • C++ failed in part because of the unfounded belief that its supporters had in its abilities..

        C++ failed? Hmm, the last time I checked one of the two OSs that I use on a regular basis is written in C++. And the web browser, email client, instant messenger, IDE, PDF viewer, source control software, mp3 player, and word processor that I have opened right at this moment is written in C++.

        Mod parent conveniently making up bullshit or funny definition of failure.

    • by Ungrounded Lightning (62228) on Tuesday March 01, 2005 @06:11PM (#11817832) Journal
      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.

      Actually there is: Co-evolving the spec documents, comments, and code. Yes it helps a LOT to plan ahead - and it's a must if you want things to have a chance of getting done in any reasonable time. But trying to cast a spec into concrete in advance of coding is a false economy, too. The spec must remain maleable so the internal problems with it that are discovered during the coding phase can be corrected.

      The thing there IS no substitute for is documentation separate from the code itself - whether it's a spec document, good comments, or (preferably) both. Self-documenting code is a falacy - because the code only documents what the code does, not what the code SHOULD do. (Grep is a great program. But it's REALLY broken if what you wanted was cat, or ftp.) Testing doesn't check that a program is "right" - only that it matches a spec. If you're trying to verify correctness of someone else's "self-documenting" code the only thing you can test is the complier. B-)

      That applies to you trying to test your OWN code later. You are not the same person you were two months - or even two hours - after you wrote it.
      • by Zaak (46001) on Tuesday March 01, 2005 @08:13PM (#11819142) Homepage
        Grep is a great program. But it's REALLY broken if what you wanted was cat, or ftp.

        Slight nitpick: cat is a subset of grep. Just use a pattern that matches every line like ".*". Granted, if you said "write cat" and your programmer wrote grep, you should have a talk with him about creeping featuritis.

        Other than that I agree.

        TTFN
    • Re:False Economy (Score:5, Insightful)

      by Viking Coder (102287) on Tuesday March 01, 2005 @07:05PM (#11818370)
      I can't read someone else's architectural design. I have no idea how the problem domain works. I have no idea what kinds of generalizations and concepts were used to break the problem down. I have no idea which facets of the problem were important, and which could be ignored. I don't know anything about the material sciences involved. What I don't know could just about fill the Grand Canyon.

      Why do you presume that reading a software design (source code) would be any different?

      It's hard to read a design - even a good one - until you "get it." Until you grok it. Those other documents you talk about are freaksihly important, and the author doesn't deny that - but they are not the design. They are of fundamental importance to the success of the design, but we shouldn't pretend that they are the design.

      You're absolutely right to refer to those things as "documents." They help document. But they are not the design.

      He's not saying skip design, he's saying that you do what you have to, in order to think the problem through (some design, some documentation, some testing, etc.), and then you work on the real, actual design (the source code.)

      Refering to "the initial programmer" like you do is completely ignoring everything he's saying.
      • The source code isn't the design - that's the whole point. The specs, the flowcharts, the use case docs that state the issues, the problems, the solutions. In language presented to a person with competence in the human language (eg. English), and enough competence in the domain jargon to use a glossary, if necessary. The source code is too idiosyncratic to be design that's usable later - especially because procedural languages are based on inventing new vocabularies (function and variable names) for every a
    • Re:False Economy (Score:4, Interesting)

      by iabervon (1971) on Tuesday March 01, 2005 @07:51PM (#11818946) Homepage Journal
      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.

      Those are the worst. You have the source, which seems to almost work. Then you've got the comments in the code, which are sort of relevant, but whenever the code gets sufficiently tricky that you'd have to read any of the comments, they're simply wrong. Then there are all the dependencies, which are incomplete and only include the obvious connections and not the ones which were added later. Finally, there are the requirements, which not only don't describe the actual program, but are simply impossible.

      The best projects are ones where there's a bunch of code, which is written with names that suggest what things actually are and do, where everything is broken down into chunks which are sufficiently small to understand if you look at them, which has gotten arranged so that everything flows in accordance with the underlying problem being solved, and which is grouped logically, with related functions near each other within a file, in files, and in directories; and there is additional documentation, revised after the last change to anything it documents, which explains everything that isn't obvious from reading the code, as well as explaining where in the code to start reading.

      The sole reason that code is the best documentation is that it is never incorrect. The program will definitely do what its source says it will. All other documentation must be held to the same standard, even though there is no automatic check for it. (One advantage of javadoc-style tools is that there are some automatic checks for accuracy; you can't have javadoc which gives the wrong name for a function). The worst thing is documentation which pretends to be authoritative, but which is out of date, and any document which predates the code is going to be out of date, unless the project is so trivial that someone with no experience could do it on the first try-- because that is what the original design documents are: the first try by people who do not yet have experience.

      Personally, I think the best balance might be to start writing code with minimal planning (come up with the idea, divide the tasks, decree the coding style, arrange the process for adding tasks), but to have bitter and anal code reviews of everything that goes in. This requires the programmers to demonstrate that the code is clear enough to read and that the result including all additional documents is accurate and sufficient for someone who didn't write it to understand it based exclusively on the design.
    • Re:False Economy (Score:3, Informative)

      by dubl-u (51156) *
      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 muc
  • A nice quote (Score:5, Insightful)

    by tcopeland (32225) * <tom@@@thomasleecopeland...com> on Tuesday March 01, 2005 @05:47PM (#11817576) Homepage
    > Personally, I think a person with his feet on
    > the desk staring at the ceiling can be "doing
    > design" just as seriously as someone playing
    > with UML diagrams in ROSE.

    So true. Although I find it helpful to move along these reveries by writing little test apps to put wheels on some ideas... just little 10-20 liners to help get a better handle on things.
    • > Personally, I think a person with his feet on
      > the desk staring at the ceiling can be "doing
      > design" just as seriously as someone playing
      > with UML diagrams in ROSE.

      I think I used to maintain that guy's code, no documentation written anywhere and the code looks like it was written as several different prototypes and then jumbled together in some form of working fashion.

      While I realize this is not always the case and I write code the same way myself, the real benefit to "writing documentati

      • The problem with writing the documentation down at the beginning of a project is that in the "Real World" its obsolete the moment you open up a text editor. As much as everyone would wish for requirements to be laid out up front and set in stone before a single line of code was typed, it just doesn't happen in many, if not most, cases.

        And when it does happen, that documentation time and money goes down the drain. If you had simply written well documented code to start with, that new requirement could hav
    • True, indeed. But don't discount UML just because it is often misused. The significant advantage of UML is that it is communication: it allows a developer to implement a design (or, indeed, component) in any langauge.

      This is advantageous when your job is to design, and pass the implementation off to someone else. Of course, using UML is not and should not be a substitute for the creative design process. I encourage designers to think out thier designs using whatever method works best: flowcharts, psued

    • Re:A nice quote (Score:3, Interesting)

      by Viking Coder (102287)
      Reminds me of Richard Feynman's Problem-Solving Algorithm:

      1) Write down the problem
      2) Think very hard
      3) Write down the solution
  • and can only describe how much i agree with this in utterly banal terms.

    code is design.

    take any programming language, whatever virtue, whatever failure, it does not matter. the fact that it is a language at all, proves it.

    because any single language exists solely and uniquely by and for design. language is for designing things, and describing the design of things to other people, over a process called 'time'.

    design implies persistence, and as we all know, time destroys all things. language is design o
  • by GillBates0 (664202) on Tuesday March 01, 2005 @05:51PM (#11817627) Homepage Journal
    Probably something like this?

    X=1024; Y=768; A=3;

    J=0;K=-10;L=-7;M=1296;N=36;O=255;P=9;_=1<< 15;E;S;C;D;F(b){E="1""111886:6:??AAF"
    "FHHMMOO555 57799@@>>>BBBGGIIKK"[b]-64;C="C@=::C@@==@=:C@=:C@= :C5""31/513/5131/"
    "31/531/53"[b ]-64;S=b<22?9:0;D=2;}I(x,Y,X){Y?(X^=Y,X*X>x?(X^=Y) :0, I (x,Y/2,X
    )):(E=X); }H(x){I(x, _,0);}p;q( c,x,y,z,k,l,m,a, b){F(c
    );x-=E*M ;y-=S*M ;z-=C*M ;b=x* x/M+ y*y/M+z
    *z/M-D*D *M;a=-x *k/M -y*l/M-z *m/M; p=((b=a*a/M-
    b)>=0?(I (b*M,_ ,0),b =E, a+(a>b ?-b:b)): -1.0);}Z;W;o
    (c,x,y, z,k,l, m,a){Z=! c? -1:Z;c <44?(q(c,x ,y,z,k,
    l,m,0,0 ),(p> 0&&c!= a&& (p<W ||Z<0) )?(W=
    p,Z=c): 0,o(c+ 1, x,y,z, k,l, m,a)):0 ;}Q;T;
    U;u;v;w ;n(e,f,g, h,i,j,d,a, b,V){o(0 ,e,f,g,h,i,j,a);d>0
    &&Z>=0? (e+=h*W/M,f+=i*W/M,g+=j*W/M,F(Z),u=e-E*M,v=f-S*M,w =g-C*M,b=(-2*u-2*v+w)
    /3,H(u*u+v*v+w*w),b/=D,b*=b ,b*=200,b/=(M*M),V=Z,E!=0?(u=-u*M/E,v=-v*M/E,w=-w* M/
    E):0,E=(h*u+i*v+j*w)/M,h-=u*E/(M/2),i-=v*E/(M/ 2),j-=w*E/(M/2),n(e,f,g,h,i,j,d-1
    ,Z,0,0),Q/=2,T/ =2, U/=2,V=V<22?7: (V<30?1:(V<38?2:(V<44?4:(V==44?6:3))))
    ,Q+=V&1?b: 0,T +=V&2?b :0,U+=V &4?b:0) :(d==P?(g+=2
    ,j=g>0?g/8:g/ 20):0,j >0?(U= j *j/M,Q =255- 250*U/M,T=255
    -150*U/M,U=255 -100 *U/M):(U =j*j /M,U<M /5?(Q=255-210*U
    /M,T=255-435*U /M,U=255 -720* U/M):(U -=M/5,Q=213-110*U
    /M,T=168-113*U / M,U=111 -85*U/M) ),d!=P?(Q/=2,T/=2
    ,U/=2):0);Q=Q< 0?0: Q>O? O: Q;T=T<0? 0:T>O?O:T;U=U<0?0:
    U>O?O:U;}R;G;B ;t(x,y ,a, b){n(M*J+M *40*(A*x +a)/X/A-M*20,M*K,M
    *L-M*30*(A*y+b)/Y/A+M*15,0,M, 0,P, -1,0,0);R+=Q ;G+=T;B +=U;++a<A?t(x,y,a,
    b):(++b<A?t(x,y,0,b):0);}r(x, y){R=G=B=0;t(x,y,0,0);x<X?(printf("%c%c%c",R/A/A,G
    /A/A,B/A/A),r(x+1,y)):0;}s(y){r(0,--y?s(y),y:y); }main(){printf("P6\n%i %i\n255"
    "\n",X,Y);s(Y);}

    Courtesy IOCCC:http://www0.us.ioccc.org/2004/gavare.c
  • by syousef (465911) on Tuesday March 01, 2005 @05:54PM (#11817664) Journal
    Does this sound a lot like "The Network is the Computer" to anyone?

    Stop with the pseudo-clever melodramatic BS already.

    Good code following the design is nothing new. Jumping straight into coding without a design document that the WHOLE team AND your clients/users can read however is insane.

    I'm all for productive laziness but this is just plain BS.

    • Does this sound a lot like "The Network is the Computer" to anyone?

      It does - but that phrase seems to be the submitter's invention, at least from a cursory look at the fine article. Reeves's point is much more sublte and interesting:

      The final goal of any engineering activity is the some type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team. This is a completely different group with completely different skills from the design team. I

      • The author's conceptions about the manufacturing world are entirely wrong.

        In the manufacturing world, seperating your design and manufacturing departments leads to parts which are very expensive (if even possible) to manufacture.

        The end goal of a small production product is not the specifications. It is typically a list of raw materials, tools, a plant specific part routing, step by step directions for every cut and alignment need, CNC programs, and a testing program. These specific instructions (p
        • Huh. Funny. So, you're saying that the design department never touched a CNC machine, and somehow they magically produced a correct CNC program?

          Of course not. That's because design and manufacturing, in every succesful company, know an awful lot about each other.

          How much do you know about your compiler? And when you're done linking source code, how much does your compiler know about your design?

    • Jumping straight into coding without a design document that the WHOLE team AND your clients/users can read however is insane.

      Did you even read the article? He clearly and specifically addresses this misconception of what he's saying at least three times that I can remember off the top of my head.

      To summarize it for you (since you're such a fan of laziness that you won't even try to understand someone's point before you try to shoot it down): everything you call "design" is important - really, really imp
      • I did read the article and what I was saying is that his melodramatic way of stating the freaking obvious is unimpressive.

        If you put something in such a way its so easy to misconstrue while simultaneously trying to put yourself up as an nisightful guru you'd better expect intelligent people who aren't bamboozled to say "hang on a minute".
  • Sigh (Score:4, Insightful)

    by DanielMarkham (765899) on Tuesday March 01, 2005 @06:02PM (#11817752) Homepage
    Perhaps slashdot should have a special section for newbies who don't want to do the hard work of creating software and would rather just hack.

    Yes, staring at the ceiling can be just as good as playing with UML. But your job is to communicate -- to the team, to the customer, to the poor maintenance programmer -- just what the heck you are trying to accomplish in your code. The "being the smart kid" should be the easy part. The "getting clarity and agreement on scope and solution space" is what they are paying you for.

    I've found that it is very hard to communicate to the customer the contents of a switch statmenet using polymorphism. Hence the reasons for layers of abstraction. Model, design, plan at just enough detail that you can communicate and agree on a strategy with all the stakeholders. Then go play with the bits and bytes.
    • Perhaps slashdot should have a special moderation value for newbies who don't want to do the hard work of RTFA and would rather just bitch.

      The compiler doesn't care how much you communicated. Clearly you need to communicate to solve sufficiently large problems. He never said anything different! Everything you do, right up until the point where you type actual code makes no difference to the compiler. Since the finished product (the executable) is what you intend to build, and the compiler actually buil
  • My company. (Score:5, Funny)

    by inertia@yahoo.com (156602) * on Tuesday March 01, 2005 @06:03PM (#11817754) Homepage Journal
    Whenever I bring stuff like this up to the powers that be, their response is basically just, "Shut-up and code." Then conversations like this take place between employees:

    Dilbert: I'd quit and become an entrepreneur, but I don't know how they handle such huge risks.
    Wally: Denial, probably.
    Alice: We got bought by our arch-rival this morning. Their CEO says he plans to be as "humane" as possible.
    Dilbert: He sounds nice.
    Wally: Maybe we'll get bonuses.
  • Flex (Score:2, Interesting)

    by jwegy (775655)
    Design importance has a direct relationship to the size/complexity of the system being designed AND the "system" that is designing the system. By that I mean, design is a loose term. Me and my roomate can design better by talking about a general idea, and then sitting down and writing code while making adjustments where needed. This process wouldn't work in most coroporate cube farms where you have varying levels of skill, vision, ability to learn, types of users, and the all knowing PHB. This is a stereo
  • I agree completely (Score:5, Insightful)

    by MCTFB (863774) on Tuesday March 01, 2005 @06:09PM (#11817815)
    There are many styles to writing code, but I think that if you are verbose with the naming of your variables, as opposed to naming your variables with unintelligible abbreviations, then that goes a long way to long term code maintenance.

    Well written code should read like a book and only need commenting for blocks of code which are not completely obvious as to what their intent happens to be (for example some hack you write up to get around a bug in a library you are using at the time).

    One of the most annoying things is the fact I choose not to use an IDE, so developer documentation inserted into the code to describe a function or class or whatever just clutters up the reading of the actual code.

    Furthermore, most of the developer documentation of your typical programmer is such that all it describes is the arguments a function takes and what is supposed to be returned, while doing nothing to explain the purpose of the function and why it might be used. In other words, most of the time documentation is useless and just gets in the way because it doesn't relate to anything which makes sense (for humans to understand something new, usually you need to relate it to something they already understand).

    So as a general rule of thumb, if you can read the code out loud (or in your head) and you don't constantly have to stop to analyze the code to see what the context of some variable happens to be at any given time, then you are doing a good job. If on the other hand your code cannot be read out loud (because of inaudible variable names), then the odds are some other programmer is going to have to review every other line of your code just to try and make sense of it all.

    An ex-employee of mine who I didn't audit very well, spent a ton of time documenting his code in some of the most anally-retentive ways. However, his code just never had any flow. To date, I have had to scrap much of what he worked on because his code was not maintainable.

    So in essence, if you have poorly written code, then all the documentation in the world won't do much because poorly written code makes your design inflexible and hard to work with, while well-written code that you can read like a book usually is simple enough that you can mold it into something more useful later on.

    So I agree that the code is the design and the design is the code. You can come up with the most elaborate UML diagram known to man, but if the code has no flow to it, and a whole lot of hacks are needed to implement a rigid design structure, then the design overall in the end is going to suck.

    If you are going to do documentation, keep your modules small and do it once you are pretty certain the modules won't be changing much from that point on. If you are uncertain, then it is probably best to just ignore the documentation process until things are more set in stone.
  • by photon317 (208409) on Tuesday March 01, 2005 @06:10PM (#11817828)
    I won't argue the point, as he does a better job than I could, but I whole heartedly agree with his take on the matter. Especially that paragraph in the "new" essay (2nd one of the 3 in the linked page) that makes the analogy about doctors in discussing the "Less Able Programmer" problem.
  • Dangerous.... (Score:2, Interesting)

    by Anonymous Coward
    While it may be true that designing is the most critical part of coding, it's dangerous to equate the code and the design. Because that implies, obviously, that writing code is the same as designing it, so just skip any forethought about design concerns and launch right into the coding.

    I will admit to being a project manager, not a developer. And I know that thinking through requirements and design specs is the "eat your vegetables" part of programming, and no one really enjoys it nearly as much as writi
    • Re:Dangerous.... (Score:4, Insightful)

      by dubl-u (51156) * <2523987012@@@pota...to> on Tuesday March 01, 2005 @10:58PM (#11820423)
      While it may be true that designing is the most critical part of coding, it's dangerous to equate the code and the design. Because that implies, obviously, that writing code is the same as designing it, so just skip any forethought about design concerns and launch right into the coding.

      Sweet Jesus! Did you even read the articles linked? For example, this part?
      Nevertheless, people keep insisting that my contention of "the source code is the design" means "don't do design, just code." I never said anything of the sort.

      If you're going to misunderstand the guy, you could at least do it in a new and interesting way.

      I will admit to being a project manager, not a developer.

      Ah, so that's why you feel qualified to give opinions on something you didn't even take the time to do the reading on.
  • by reallocate (142797) on Tuesday March 01, 2005 @06:13PM (#11817850)
    It's always seemed to me that design and coding are more than a bit like buiding a house and using carpentry tools. The world's best carpenter won't build much of a house unless someone's done the design (even if it's just one more 3-bedroom ranch he's built many times before -- that design is imprinted in his memory.)

    But, you can't live in a design, so both skills are needed.

    In the end, people who stand around and argue that good carpenters don't need designs, or vice versa, miss their completion date and lose the customer.

    • The whole point about software is that the "carpenter" is supposed to be automated. If the design is complete there is no need for manual translation of the design to the code. Unfortunately it's often far from complete, making many design documents a)next to useless, b)out of date the instant coding begins. That's what stuff like UML tools are trying (and largely failing miserably) to solve.
    • by waveclaw (43274) on Tuesday March 01, 2005 @09:05PM (#11819568) Homepage Journal
      It's always seemed to me that design and coding are more than a bit like buiding[sic] a house and using carpentry tools.

      I find it funny that you and many other people use Carpentry as a metaphoric model for coding. However, after working as a carpenter for over half a year I have to say that it is appropriate.

      The world's best carpenter won't build much of a house unless someone's done the design

      Houses are built as a variation on a template for their entire neighborhood. In richer areas, more variation occurs, but then more money is poured into the project. In older areas, the variation in house styles is mainly due to renovation by the various tenets over the years.

      Unfortunately, most code written is mostly re-inventing of the wheel at the design and implementation level. Closed source techniques necessitated this for a long time (the highly-copyrighted Numerical Recipes books, anyone?) Open source should change the re-inventing of the wheel, but I still see a lot of people re-inventing the wheel 6 or 7 times out of 10 projects. The 8th and 9th will probably shoehorn in a custom library of crufty utility code they wrote years ago for college homework.

      But, you can't live in a design, so both skills are needed.

      Never owned a house, have we? People who can't afford to spend a long time in a motel/hotel/vacation-resort will live in half finished (but up to code) houses and use kitchens that are being actively remodeled. Similarly, you can go grab open source projects from sourcefroge.net to do little more that compile and jump right in. If I recall correctly, I had to code a Ethernet driver module for the 1.7 kernel series. No driver existed for my card. My RedHat Linux 5.6 would loose network functionality after the install. I this any different from living in a multi-story house while the bathrooms on the other floors are being built?

      In the end, people who stand around and argue that good carpenters don't need designs, or vice versa, miss their completion date and lose the customer.

      A lot causes schedule slippage in both coding and carpentry. Both in carpentry and in programming projects regularly go over schedule. Customers are told that sickness and surprises will cause the schedules to slip on any construction. With programming projects it is hard to tell people that extra, unexpected work is needed. Showing customers the termite damage in a wall is easy, showing the hacks in a networking library is not.

      The correct people and only the correct people talk to customers. These people typically are the people or work with the people who do the design. With coders/software-designers being stereotyped as uncouth and kept away from the customer, the design may not reflect reality. When the customer is not aware of what they are asking (i.e. requirements creep) it is easy to tell them that additional carpentry and materials are not free. Management and the Customer seem to think that additional software features are not free. Your customer facing people must know when to say 'No' and when to say 'it will cost THIS much,' not pander to the idea that coder-time is free because the results aren't physical.

      With trim and paint to cover errors, you can get away with 'rules of thumb' in carpentry[1]. Some voids are needed to allow for expansion and contraction of joints. Management never seems to understand the need for well-defined APIs or plug-in architectures (let alone security or data integrity.) Plus, the computer is a little less tolerant of taking the software equivalent of power tools to the virtual memory manager.

      Come to think of it, carpentry is a very bad model for programming[2].

      ------
      1. Literally a thumb used as a ruler. With the massive non-squareness of some people's idea of a *square wall*
      you have to hate the flexibility of wood over long periodic thermal cycling. Here's a hit: like with bad code, a slightly off wall creeps further out of square with t
  • Yes, I read tfa (Score:5, Interesting)

    by chris_mahan (256577) <chris.mahan@gmail.com> on Tuesday March 01, 2005 @06:14PM (#11817864) Homepage
    The idea is that great code resembles a picasso more than a f-16 fighter.

    Picasso could not tell people how he did it, or rather people could not understand picasso's explanation.

    An F-16 fighter, however, given enough years of schooling, could be explaned in great detail to anyone. This is why, although incredibly complex, there are thousands of F-16s out there. Yet there are only Picasso's picassos.

    Likewise a great coder can't really explain how he wrote the great code. He just could. You can see the result, admire it, copy it even. But to apply the same "creative process" to a different problem, you'd have to be the original programmer.

    I say this is why great programming is art and bad programming is not. Just like picasso is an artist and the guy who repainted the wall is not. It's because the "creative process" can't be passed on. It has to be self-invented.

    Anything Shakespeare is Shakespeare. Nobody else can write Shakespeare, because they don't have the same creative process he did.

    You can study Shakespeare, Picasso, Beethoven all your life and never be able to emulate them. Likewise a great coder's code can be copied, but the process that made the code can't be replicated.

  • by kkoning (29512)
    Ultimately, I'd agree that "code is design", but that this is an overly simplified view. Looking at "x = y + z" and knowing an addition operation is being performed is one thng, but what do these symbols stand for? Why is the operation being done? How does this fit into the overall function of the software? These questions start to become more difficult and time consuming for a human being to answer without an overall design as a project increases in size and complexity.

    For example, I might be able to
  • by Anonymous Coward
    For me, I can stare at the ceiling fan and draw bubble diagrams for weeks, and actually have a decent plan ..... for some definition of "decent".

    Then I start coding, and about 10 lines into it I realize I've got a major flaw in my design that I could seen weeks ago if I'd been coding. So insofar as "The Code is the Design" stands in opposition to and absolutist commitment to "Da all Design First, Code Later" I'm 100% for it. Insofar as it stands in opposition to "Think about what you are going to do, then
  • experiment (Score:5, Funny)

    by k4_pacific (736911) <k4_pacific@noSpAM.yahoo.com> on Tuesday March 01, 2005 @06:33PM (#11818045) Homepage Journal
    I thought I'd test to see if the code really is in the design.
    > chmod +x project_design_overview.ppt
    > ./project_design_overview.ppt
    Segmentation Fault
    Nope.
  • by roman_mir (125474) on Tuesday March 01, 2005 @06:33PM (#11818050) Homepage Journal
    Yeah, the code is the documentation and the requirements and the business definition. Of-course it is if you have nothing else. That's what it becomes if noone bothers to update the docs.

    Let me tell you something about that. I have worked on way too many projects (including the current one) where this was the case - there was only code, or the docs were so out of date that really, there was only the code. It's horrific in most cases. Certainly there are horror levels but I am serious, it is just freaky.

    Do you know what happens to a project without documentation? Let me tell you what happens: the only way someone can maintain it, given strict deadlines and/or budget constraints is by fixing the bugs without actually understanding the design. So your fix becomes just a special rule for a special case and in the worst scenario it is also a fix that only works for a special kind of data. So what happens at the end with such a project? A 30 year old COBOL program situation - too many rules that are not generalized all over the place with all kinds of side-effects. Good luck supporting that shit.

    I will take a high level document describing the system any time instead of jumping into the code right away. I prefer to know the components of the system, the main players, where the configurations are, what patterns are used to develop the system before jumping into the code. It is just too damn bad that it does never happen that way.

  • by syousef (465911) on Tuesday March 01, 2005 @06:42PM (#11818119) Journal
    Take something more tangible like a car design. If you lumped destailed descriptions of all the blueprints for the individual components in a nicely bound document without any overall design schematic how hard would it be for anyone to get an overall picture of how the car would look and feel?

    What if you asked your average customer to work out if they'd like the car based on these ideas?

    This is very much like what you're asking business analysts and users to do if you provide a source code listing and nothing more. If I was in charge of a project, and that's what you handed me after I gave you business requirements, I'd seek to have you removed from the project.
  • by Anonymous Coward on Tuesday March 01, 2005 @06:48PM (#11818173)
    man did anyone actually read the damn article?

    He's not saying you don't do traditional software design work, or document. He's saying that if you compare the work that a software engineer does, it is equivlant to the design phase of normal engineering, not the manufacturing phase. That the program you deliver, is in essence, a completed "design" not a manufactured "product".

    When you roll out and install this "design" in the target environment, this is the step which equates to normal manufacturing.

    It's actually pretty insightful.
  • by QuantumG (50515) <qg@biodome.org> on Tuesday March 01, 2005 @06:50PM (#11818185) Homepage Journal
    Does any other programmers suffer from the paralysis caused by "design staff"? For every project my company starts, someone inevitably gets assigned the task of "designing it". The result is a bunch of incoherent scribbles, quasi-UML documents and vague ideas that us programmers are expected to work from. When we ask for more detail we get an insufficient answer. When we just go ahead and use our own initiative the design dude will moan that we havn't done it exactly how he wanted us to. The whole time I feel like smacking the design guy in the face and saying "why don't YOU fuckin' code it?"
  • I have to agree (Score:3, Insightful)

    by studog-slashdot (771604) on Tuesday March 01, 2005 @06:50PM (#11818189)
    Having RTFA, I agree with Mr Reeves.

    We have ISO at my orkplace. The hardware guys have a sequence of steps of design and manufacture that are well laid out. Getting this applied to the software guys has been more difficult.

    One allowable thing is to write test apps to check out areas of coding that one isn't familiar with. This mimics the hardware steps of mockups and prototyping.

    Recently I wrote a network app for the first time. Once that experimentation/research was done, I had some useful info to add to the Design (text) Doc. Once I had this much done though, when the time came to "develop" (according to ISO) the developing consisted of nothing more than cutting and pasting my test app, and tweaking some parameters.

    I've been wondering about this for a while because it didn't seem right, that I must have been doing something wrong, but the article filled in the missing understanding.

    ...Stu

  • by PepeGSay (847429) on Tuesday March 01, 2005 @07:02PM (#11818324)
    Upon reading this again... I realize that the Micrsoft Solution Framework really gets at this idea very well, while still being applicable to large projects. It also attempts to protect against "releasing demo code". It heavily advocates early and continuous builds with an ever expanding capability, so that the development is always *technically* at a releasable stage (within reason).

    Flame away for mentioning MS in a good light.
  • by Greyfox (87712) on Wednesday March 02, 2005 @01:06AM (#11821046) Homepage Journal
    Back in the day you did flowcharts or pseudocode to get a good idea of what you wanted the computer to do before you put card to keypunch. Today you do UML or pseudocode to get a good idea of what you want the computer to do before you start coding. Oddly, despite the new "paradigms" and "methodologies," project failure rates seem to remain constant.

    Over the years, management has attempted to quantify software development. They've pointed to the visible tools of the trade, the flow charts and the UML, and a lot of them have mistaken that for the process of designing software. In fact the only thing that you really need to design software is an understanding of your customer's requirements (Or your requirements) and the know-how to turn that into a working system. Unfortunately that's not quite so easy to quantify, and so most management types ignore those traits in their programmers.

    The folks who are always going on about six-sigma and CMM level 5 always seem to be stumped as to why they can't just give a chmpanzee a UML generator and churn out working project after working project. Turns out that despite all efforts, software design still requires you to think about your problem and how to get from where you are to where you want to be. Go figure.

Maternity pay? Now every Tom, Dick and Harry will get pregnant. -- Malcolm Smith

Working...