The Code is the Design
1. The Code is the Design
At university, most of us are taught that the development of a software should go through the following phases: requirement specification, design, construction (or coding), and testing. By gathering system requirements (e.g. from the clients, market researches etc.), analysts would come up with a bunch of functional and supplementary requirement documents, use case model and specifications during the requirement specification phase. Then, designers would translate these specifications into design documentations which include many diagrams (and most notably, UML) representing different aspects of the system. These diagrams are then translated, by programmers, to the code which is compiled into software to be verified by testers before being released into production. Depending on the particular process applied (waterfall, or iterative), a portion or all of the software would go through this life cycle at a point of time.
Because design is considered by everyone to be very important and complex (because it is the truth in any industry we know), what the university actually teaches us is to place a big focus on the diagrams, which are assumed to be the real and final output of the design process. It teaches us to take these diagrams for granted as much as builders take building blueprints for granted. With this perception deeply engraved into the thinking, some designers would spend most of their time elaborating the UML diagrams, thinking that they are working hard to help those poor coders to easily translate their brilliant ideas into some source code, which is considered simple to produce. Some managers and companies would decompose their team into separate groups of designers, who do design task, and coders, who do construction task and it is almost always the case that designers are considered more senior or “high-level” citizens than their coders fellows. No wonder why so many software projects fail…
If you are still among the people who believe that the essential output of the design process is the UML diagrams, that a bunch of comprehensive and elaborated UML diagrams would promise a successful project, and that software design and construction are similar to building design and construction, I would challenge you to think about the following questions
- Have you ever been able to translate the UML diagram created by some other folks into some source code which 100% match with what described in those diagrams? (First, I am not talking about Hello World, if you happen to have some UML diagrams for it . Second, in building construction, it is almost always the case that the building realizes everything mentioned in the blueprints.)
- Have you ever been looking at a bunch of UML diagrams and say to yourself “wow, these are cool and really elaborated, they already include everything I need to do the coding task” or “this is a very complex module but with these design diagrams in place I would be able to code it really quickly”, and your thoughts turns out to be true? (In building construction, most blueprints contain all of the details necessary for the builders to do their job.)
- Have you ever participated in any project which, at the end of the project, all of the two hundreds “comprehensive” UML diagrams served as inputs of coding activities are still in sync with the code? (In building construction, there is hardly any change to the blueprint after it is finalized in the architecting phase.)
Unless you are living in the different world from mine, the single answer to all the above questions would be: NO!!! These questions bring me to the first proposition of this post
No UML diagram is the essential and final output of the design process, the code is. And when you are coding, you are designing.
This is a powerful concept as it helps provide satisfactory answers to many issues that we are having
- Why can we not easily translate elaborated and detailed the design diagrams into the code as builders construct buildings from blueprints? Why can we not code a system right the first time, regardless of the high level of elaboration of the design diagrams? Because the coding is actually a design activity, which is highly complex and requires a lot of creativity instead of being a simple and routine effort
- Why is waterfall process a big failure (besides conventional reasons such as lack of early feedbacks, errors take long to be detected etc.)? Because this process erroneously assumes a design phase with an bunch of documentations and diagrams as outputs and these outputs must be locked down before coding can start while in fact designing is not done (and thus, the diagrams cannot be fixed) until coding is done. Iterative processes allow feedbacks from later phases to shape the earlier phases, thus it is safe-guarded from this trap.
- Why some people suggest to do just enough documentation and instead focus on what they consider more important, the code, and still be able to delivery successful products (on the other hand, we almost never construct any building without a really really elaborated blueprint)? Because unlike building construction, in which the blueprint is the final output of the design process, in software, it is the code, not the documentation, which is the final output of the design process
You ask “well, if the code is the output of the design process, then what is the output of the construction phase that we study about”. It is the software. And the construction of software, unlike any other engineering disciplines, is really really inexpensive thanks to the compilers and linkers who are the “builders” in the software world and are able to take the code (blueprint) and produce the software (the building) in a matter of seconds or minutes. Now, I assume that you are on the same page with me about the actual role of coding, let’s go a bit further on what the code actually is
2. What is the Code?
My definition of software design is: any activity that requires the application of software engineering discipline and creativity to translate the system requirements into representations which can be used as immediate inputs to some generators (e.g. compilers) to produce working software systems is part of software design. In other words, the code is the representation of the design, not the design itself. That also implies, the code does not necessarily mean the Java or C# source code, instead it is anything representing the design and can be used by some generators to produce working software. In fact, if Java and C# source code can be generated from a certain specification then it is no longer considered the output of the design activity, it is then the product of the building activity. Today, the code is expressed in Java or C#, tomorrow it may not be. In fact, if MDA can go into the mainstream, then UML diagrams will eventually be considered the code. That brings me to the 2nd proposition of this post
The code is anything representing the design concepts and is expressed in a format that can be used as immediate input to the software construction phase during which compilers or generators produce the working software from the code. As a result, today, C#, Java source code is considered the code, but they may not be considered the code tomorrow
3. OK, So What Do They Really Mean To Me and Why Should I Care?
In light of the two propositions discussed in this post, let me ad
dress these questions by the following summarization
- Because the code, not the diagrams, is the essential and final output of the design, the focus of software design is the code, not the diagrams. Thus, although diagrams do have value, in demonstrating design concepts in a high-level view to certain audiences (clients, new developers etc.), the focus of designers should always be the code.
- Because the goal of the design process is to produce the code, there should be no separation line between designers and coders. Instead, there should just be one single specie: the one who produces the code. So, companies should immediately fire anyone who can draw very “cool” UML diagrams but cannot actually craft excellent code
- Today, C#, Java code etc. are considered the code, tomorrow, it may not be the same. As a consequence of this, companies who hire people who only know C# or Java (and assume that such folks are designers) would not stand very long. Companies should hire real designers, those who can digest complex system requirements and, through the design process, produce solutions which can address all those requirements and represent them in a format which can be used by “builders”.
- Real designers should not tie to any particular languages or technologies, which are meant to represent the design and will be changed over time. Instead, besides programming languages, real designers should learn about what necessary to translate the requirements into any particular representation and that includes, but not limited to, OO design principles and patterns, algorithm design, business domains, and computing theories.
4. A Look Into the Future
Twenty years ago, in No Silver Bullet, Fred Brooks argued that any software project must tackle two kinds of difficulties: the essential and the accidental. While the essential is involved with the process of precisely and richly formulating abstract design concepts, which represent solutions to the system requirements, the accidental is involved with the representation of those design concepts into a format understandable by the compilers (programming language source code). Brooks also argued that
The hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems. If this is true, building software will always be hard. There is inherently no silver bullet
While high-level languages, virtual machines, and other great tools are making the tasks of representing the design concepts easier and easier, this accidental difficulty is not completely eliminated in the current state of the industry. As a result, it is very misleading if one uses Brooks’ proposition as an argument to say that this representation process is easy: it should be, but not now. And even when this is completely eliminated, we can still rest assured for the fact that the essential difficulties are still there to challenge our ability…
- “What is software design”, Jack W. Reeves, C++ Journal, 1992
- “No Silver Bullet: Essence and Accidents of Software Engineering”, Frederick P. Brooks, Jr., Computer, Vol. 20, No. 4 (April 1987) pp. 10-19