The State of Software Development

I've been writing this column for a year now. Are we getting better, or is software just getting flashier?

• By Mike Gunderloy
• 04/01/2002

But what does it mean to be a better developer? In 2002, one of the biggest pieces of being a better developer is to write code that people can understand. I can already hear the grumbling from the other side of the monitor: "I don't need no steenkin' code reviews. My code works and that's what's important. If people can't understand it, that's their problem."

Let me try to explain why I think it should be your problem too.

Brilliant but Flawed
Here's a relatively famous section of one of the early releases of Unix:

/*
* Switch to stack of the new process and set up
* his segmentation registers.
*/
retu(rp->p_addr);
sureg();
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
   rp->p_flag =& ~SSWAP;
   aretu(u.u_ssav);
}
/*
* The value returned here has many subtle implications.
* See the newproc comments.
*/
return(1);

Dennis Ritchie, who helped write this code and the associated comments, is a smart guy. He's much smarter than I am, that's for sure. Nevertheless, I think that writing that set of comments and then later trying to defend them as good comments (see his web page at http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) indicates a fundamentally misguided approach to software development. (OK, to be fair, it indicates a fundamentally misguided approach to software development to write those comments today. The situation was a bit different in 1975, when hardware was slow and expensive with little storage).

At least I can brag that I've made the same mistake myself. I recall eventually writing in the comments of a project I was working on:

' It works, don't mess with it

So what's the problem here? The problem is that this sort of comment indicates two things. First, the person who wrote the comments likely felt that the code was something that the maintenance programmer later on should just accept as having been handed down from on high. Second, the author more than likely didn't understand the code himself.

Folks, there are smart people in this business, but there are no gods writing code. Code doesn't come down to us on stone tables. Ritchie admits that his block of code had to be ripped out and replaced because it didn't actually work. In the case of the product I was working on, the code developed so many layers of poorly understood cruft that no one wanted to touch it any longer, and new features could not be safely added.

So, there's one strike against incomprehensible code: It's a place for bugs to lurk and breed.

Untrustworthy Computing
I spent quite a bit of time in mid-July last year removing servers from the Internet and reformatting them. Of course, I wasn't the only one doing that. You may recall that as the month that the Code Red worm blew through IIS servers like a measles outbreak in an unvaccinated population.

Now, I haven't seen the IIS source code. But I'll bet that it didn't contain a comment like this:

/* Assume that no one will ever send more than 240 bytes of data */

More likely the comment is something like this:

/* Translate the buffer to Unicode so we can use the W-version APIs */

Whatever it said, though, you can bet that several people at Microsoft looked at the code in the ISAPI dll that Code Red exploited. And testers made sure that it did what it was supposed to. Microsoft doesn't hire stupid people and their test cases more than likely verified proper functioning for a wide variety of inputs.

And we still had those awful few days of watching our servers crash.

The lesson? It's not enough that your code performs its intended function properly. These days, we also have to worry about people trying to actively misuse the code. That's why Microsoft's developers took the entire month of February off to think about security, learn about security, practice writing secure code, and audit their existing code for security holes. And you can bet that now Microsoft's code review process includes checks for security as well as for correctness.

But why stop there? There are other metrics than correctness and security that you can use to judge your code. Is it reliable? Maintainable? Scalable? Extensible? It takes an exceptional developer to look at a piece of code and evaluate it against all those different metrics. In fact, I'm not sure I know any developers who are that exceptional. When you're auditing code for security, it's hard to keep scalability in mind. That's why we—as a profession—invented code reviews and code walkthroughs. The more eyes that look at a chunk of code, the better the chance that it will be evaluated against all the metrics that are important to the organization.

A Trap of Your Own Devising
There's a third reason that you should strive to write comprehensible code: If you're the only one who understands your code, you're stuck with it. Let's think this through, shall we? Suppose you've just finished the code for WhizBangStudio version 1.0, it's been tested and shipped and you've recovered from the hangover that you got from the launch party. Now you go to your boss and say, "OK, I'm ready to try something new, what's the next project?" How are you going to feel when she says, "Well, actually, we need you to work on WhizBangStudio 1.1. The maintenance programmers say they can't understand your code, and we really need to insert a few new features."

Now, I know that there are some people out there whose firmest desire for their job is to find a niche and stay there while the moss grows on their monitor and the cobwebs bind them to their chair. Personally, I don't understand those people, and the majority of the good developers that I know don't seem to be in that class. What's interesting to us is not solving the last problem for the second time, but finding the next problem and figuring out how to solve that.

If you write code that you alone can understand, you become indispensable. In an era of dot-com failures, that offers a certain amount of job security, but it can also lock you into a position when you'd rather move on. You'll also end up being a source of stress to your manager, who won't want a single point of failure in the organization. Expect some scheming over how they can replace you, or your section of the code, with someone who's more of a team player. Jim McCarthy has a few words of advice on this in his Dynamics of Software Development (Microsoft Press, 1995):

The brilliant developer must be capable of playing on a team, making his work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and although there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time.

Coda
I'm sure some of you are wondering at this point how I got from the state of software development to the importance of comprehensible code and teamwork. Isn't the state of the art about the latest tools and languages and techniques? Web Services and XML and C# and all that jazz?

Well, in a word, no. The state of software, as far as I'm concerned, is about the issues that most concern us in the software world. InfoWorld's P.J. Connolly recently nominated "hostile code" as the Technology of the Year for 2001 (apparently his editors thought he was joking, because they chose Web Services instead). I think you can make a fairly strong case that he's right. Anyone who's suffered through holes in technologies ranging from IIS to Oracle 9i AS to SSH over the past year knows that many of the most clever developers are apparently devoting themselves to making our lives miserable, with great success.

But I think 2002 could be the year that the balance tips back in the opposite direction. I don't think people writing applications and operating systems are stupid. I think we've let ourselves be mesmerized by the promise of our software, without giving sufficient thought to those people who would try to subvert it. We have a pretty good idea how to fix this, though: Work together, write good code, and review it with an eye to more metrics than just performance and correctness. Developers who can follow through on this plan are the ones who are going to determine the state of software over the coming months and years. Or, by default, it will continue to be the script kiddies and crackers who dictate how things work. I know which outcome I'd prefer.