Software Design and Programmers - Part 1

How important are software design skills to a programmer? Programmers, in the traditional, and perhaps most widespread, view of the software development process, are not themselves seen as designers but rather as people who implement the designs of other people. The job of the programmer, after all, is to write code. Code is viewed as a "construction" activity, and everyone knows you have to complete the design before beginning construction. The real design work is performed by specialized software designers. Designers create the designs and hand them off to programmers, who turn them into code according to the designer’s specifications. In this view, then, the programmer only needs enough design skills to understand the designs given to him. The programmer’s main job is to master the tools of her trade.

This view, of course, only tells one story, since there is great variety among software development projects. Let’s consider a spectrum of software development "realities." At one end of the spectrum we have the situation described above. This hand-off based scenario occurs especially on larger, more complex projects, and especially within organizations that have a longstanding traditional software engineering culture. Specialization of function is a key component on these kinds of projects. Analysts specialize in gathering and analyzing requirements, which are handed off to designers who specialize in producing design specifications, which are handed off to programmers who specialize in producing code.

At the opposite end of the spectrum, best represented by the example of Extreme Programming (XP), there are no designers, just programmers, the programmers are responsible for the design of the system. In this situation, there is no room for specialization. According to Pete McBreen, in his excellent analysis of the Extreme Programming methodology and phenomenon, Questioning Extreme Programming, "The choice that XP makes is to keep as many as possible of the design-related activities concentrated in one role—the programmer." [McBreen, 2003, p. 97] This reality is also well represented in a less formal sense by the millions of one or two person software development shops in which the same people do just about everything—requirements, design, construction, testing, deployment, documentation, training, and support.

There is one thing that all of the points along this spectrum have in common: even in the "programmers just write the code" software engineering view, all programmers are also software designers. That bears repeating: all programmers are also software designers. Unfortunately, this fact is not often enough recognized or acknowledged, which leads to misconceptions about the nature of software development, the role of the programmer, and the skills that programmers need to have. (Programmers, when was the last time you were tested on, or even asked about, your design skills in a job interview?)

Imagine that you know nothing about software development. So, to learn about it, you pick up a book with "Software Engineering," or something similar, in the title. Certainly, you might expect that software engineering texts would be about engineering software. Can you imagine drawing the conclusion that writing code is simple—that code is just a translation of a design into a language that the computer can understand? Well, this conclusion might not seem so far-fetched when it has support from an authority:

The only design decisions made at the coding level address the small implementation details that enable the procedural design to be coded.

Finally, you decide that you simply read the wrong section of the software engineering book, so you try to find the sections that cover coding. A glance at the table of contents, however, shows few other places to look. For example, Software Engineering: A Practitioners Approach, McGraw-Hill’s best-selling software engineering text, does not have a single program listing. Neither does it have a design that is translated into a program. Instead, the book is replete with project management, cost estimation, and design concepts.

Extreme Programming has at its core the idea that the code is the design and that the best way to simultaneously achieve the best design and the highest quality code is to keep the design and coding activities tightly coupled, so much so that the they are performed by the same people—programmers. Two other key XP concepts, "test first design" and automated unit testing, are based on the idea that, not only is the code the design, but the design is not complete unless it can be verified through testing. It is, of course, the programmer’s job to verify the design through unit testing.

Perhaps this is because, as Whittaker and Atkin point out, too much of the software engineering literature neglects the role of the programmer.
In 1992, C++ guru Jack W. Reeves published an influential article called "What is Software Design?" in the magazine C++ Journal. McBreen identifies this article as having been influential on the Extreme Programming community, and one would expect, Kent Beck.2 Reeves offers some key insights relative to the discussion at hand:

"C++ has become popular because it makes it easier to design software and program at the same time." [

"After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings." [Reeves, 1992] (Actually, Gerald Weinberg made this exact point many years earlier in an essay entitled "A Lesson from the University," published in the book Understanding the Professional Programmer.)

"The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of the design." [Reeves, 1992]

"Testing is not just concerned with getting the current design correct, it is part of the process of refining the design." [Reeves, 1992]