The tendency of some (many) software professionals to focus on The Code as the most important part of a software system, ignoring minor details like design, architecture, documentation, requirements, and (oh, yeah) the users.

In music, this would be roughly analogous to valuing the score (sheet music showing the specific notes) in an artist's song over the form, structure, creativity, and spirit that the specific notes support.  ''Actually, a given performance of a song based on the score would be analogous to the code.  The score is more like a formal design.''

''Sounds more like valuing the song over critique and analysis of the song.''

''The program '''is''' the most important thing -- the only essential thing.  The rest of the items mentioned above are either concepts (design, architecture, requirements) usually best described by the code, but often very loosely described with pictures and words, or else nonessential artifacts (documentation, users) that usually prove handy.  (Just kidding about the users.)''

Actually, the only ''essential'' thing is the ''executable''.  That's all we get when we buy crap from Microsoft.  (Yeah, yeah, you also get DLLs, help files, etc.)  Take a step back, and then you have source code, which you can (presumably) use to (re)build the executable.  Depending on the quality, readability, structure, etc. of the source code, you can modify it to make the resulting executable better, or do something somewhat different.  But take ''another'' step back and you have the architecture or design of the software, the concepts and ideas and '''understanding''' of the problem domain that the original developers achieved.  Depending on what you are trying to accomplish, these high-level "artifacts" can be more valuable than the source code.

Think about the word "code."  Code is what cryptologists use to ''hide the meaning'' of an important message, to make it ''secret''!  In our discipline, source code is what software engineers use to communicate detailed instructions to computer tools which operate on a very low level of cognitive ability.  It is (currently) a necessary tool in building software, but it is not the be-all or end-all.  It is the bricks used to build a building; but those ''bricks are not the design of the building''; they ''implement'' the design, they ''realize'' the architecture.

----

I might agree with this if the ultimate goal of software design weren't working software. In the end, the most important thing is that the darn thing makes the computer do what you want it to do. Directly, that's machine code. Less directly (skipping a few steps in the cases of, say, Perl and Java), it's the source code.

Source code has two primary audiences: compilers and people. So it's sufficiently unambiguous, understandable by humans, and provable (we can compile it and see if it does what we think it will do). I can't think of a better specification language for an architecture.

I you want to use a CASE tool to generate code from, say, UML diagrams, that's fine, too; the diagrams have become code. If you have to add to the generated code, however, be aware that your diagrams are incomplete. If you have to change the generated code, be aware that your diagrams are, to some degree, a misrepresentation of the final product -- and therefore, its architecture.

Anything that doesn't compile and execute is just theory; it may be useful to help envision what needs to be built, but the truth is what works. Code works (compiles, executes, does the job). Diagrams, generally, don't. I don't regard this attitude as CodeWorship; I regard it as common sense. --PhilGroce

''Why do we have to choose between code and graphical models and source code?  Let's try another analogy: you use recipes to cook food.  The "ultimate goal" of this process is the food, of course.  But would you cook a recipe once, then throw the recipe away?  Of course not.''

----

See also the (dubious) SecondLawOfProgramming.


And don't forget the tests.

----

	* http://c2.com/~ward/pdp8sim/ -- a shrine to code