Reviews Of Software Design and Programmers

How important are software design skills to a programmer? Programmers, in the traditional, and perhaps most widespread, view of the software development process, or others .

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.

Many other realities fall somewhere in between the two poles a) of pure, traditional, segmented software engineering, where highly detailed “complete designs” are handed off to programmers, and b) Extreme Programming and micro-size development teams, where programmers are the stars of the show. In the “middle realities” between these poles there are designers, lead programmers, or “architects” who create a design (in isolation or in collaboration with some or all of the programmers), but the design itself is (intentionally or unintentionally) not a complete design. Furthermore, the documentation of the design will have wide disparities in formality and format from one reality to another. In these situations, either explicitly or implicitly, the programmers have responsibility over some portion of the design, but not all of it. The programmer’s job is to fill in the blanks in the design as she writes the code.

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?)

In an article for IEEE Software magazine called “Software Engineering Is Not Enough,” James A. Whittaker and Steve Atkin do an excellent job of skewering the idea that code construction is a rote activity. The picture they paint is a vivid one, so I will quote more than a little from the article:

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. [Pressman, 1997, p. 346]

Really? How many times does the design of a nontrivial system translate into a programming language without some trouble? The reason we call them designs in the first place is that they are not programs. The nature of designs is that they abstract many details that must eventually be coded. [Whittaker, 2002, p.108]

The scary part is that the software engineering texts that Whittaker and Atkin so skillfully deride are the standard texts used in college software development courses. Whittaker and Atkin continue with this criticism two pages later:

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. Software Engineering: Theory and Practice, Prentice Hall’s bestseller, does dedicate 22 pages to coding. However, this is only slightly more than four percent of the book’s 543 pages. [Whittaker, 2002, p. 110]

(I recommend seeking out this article as the passages I have quoted are only a launching point for a terrific discussion of specific issues to consider before, during, and after code construction.)

Given a world where “coding is trivial” seems to be the prevailing viewpoint, it is no wonder that many working software professionals sought a new way of thinking about the relationship between and nature of design and construction. One approach that has arisen as an alternative to the software engineering approach is the craft-based approach, which de-emphasizes complex processes, specialization, and hand-offs.1 Extreme Programming is an example of a craft-centric methodology. There are many others as well.

Extreme Programming, and related techniques such as refactoring and “test first design,” arose from the work Smalltalk developers Kent Beck and Ward Cunningham did together. The ideas Beck and Cunningham were working with were part of a burgeoning object oriented movement, in which the Smalltalk language and community played a critical role. According to Pete McBreen in Questioning Extreme Programming, “The idea that the source code is the design was widespread in the Smalltalk community of the 1980s.” [McBreen, 2003, p. 100]

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. Refactoring, a key XP concept, codifies a set of methods for incrementally altering, in a controlled manner, the design embodied in code, further leveraging the programmers role as designer. 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.

It is not much of a stretch to conclude that one of the reasons Extreme Programming (and the Agile Methodology movement in general) have become so popular, especially with people who love to write code, is that they recognize (explicitly or implicitly) that programmers have a critical role to play in software design—even when they are not given the responsibility to create or alter the “design.” Academics and practitioners who champion the traditional software engineering point of view often lament that the results of their research and publications do not trickle down fast enough to practicing software developers.