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?
Over the past year, I've been hammering at the notion that you can and
should work hard to be a better software developer. I've talked about
classic books like The
and I've looked at new trends like XP
." My goal remains the same as it was a year ago: to get
you to think about the software development process so that you become
a better developer.
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
* Switch to stack of the new process and set up
* his segmentation registers.
* 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.
rp->p_flag =& ~SSWAP;
* The value returned here has many subtle implications.
* See the newproc comments.
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.
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
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
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.
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.