Code Worship

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.

EditText of this page (last edited July 24, 2009) or FindPage with title or text search