API Design Matters Stonebraker and Seltzer - RabbitMQ

programmer to know how to write various data structures
and manipulate them efficiently.
We have moved on considerably since then. Virtually
every major development platform today comes with
libraries full of pre-canned data structures and algorithms.
In fact, these days if I catch a programmer writing a
linked list, that person had better have a very good reason
for doing so instead of using an implementation provided
by a system library.
Similarly, in the ’70s and ’80s, if I wanted to create
software, I had to write pretty much everything from
scratch: if I needed encryption, I wrote it from scratch;
if I needed compression, I wrote it from scratch; if I
needed inter-process communication, I wrote it from
scratch. All this has changed dramatically with the open
source movement. Today, open source is available for
almost every imaginable kind of reusable functionality.
As a result, the process of creating software has changed
considerably: instead of creating functionality, much of
today’s software engineering is about integrating existing
functionality or about repackaging it in some way. To
put it differently: API design today is much more important
than it was 20 years ago, not only because we are
designing more APIs, but also because these APIs tend to
provide access to much richer and more complex functionality
than they used to.
Looking at the curriculum of many universities, it
seems that this shift in emphasis has gone largely unnoticed.
In my days as an undergraduate, no one ever bothered
to explain how to decide whether something should
be a return value or an out parameter, how to choose
between raising an exception and returning an error code,
or how to decide if it might be appropriate for a function
to modify its arguments. Little seems to have changed
since then: my son, who is currently working toward a
software engineering degree at the same university where
I earned my degree, tells me that still no one bothers to
explain these things. Little wonder then that we see so
many poorly designed APIs: it is not reasonable to expect
programmers to be good at something they have never
been taught.
Yet, good API design, even though complex, is something
that can be taught. If undergraduates can learn
how to write hash tables, they can also learn when it is
appropriate to throw an exception as opposed to returning
an error code, and they can learn to distinguish a
poor API from a good one. What is needed is recognition
of the importance of the topic; much of the research and
wisdom are available already—all we need to do is pass
them on.
more queue: www.acmqueue.com
carEEr Path
I am 47, and I write code. Looking around me, I realize
how unusual this is: in my company, all of my programming
colleagues are younger than I and, when I look at
former programming colleagues, most of them no longer
write code; instead, they have moved on to different positions
(such as project manager) or have left the industry
entirely. I see this trend everywhere in the software industry:
older programmers are rare, quite often because no
career path exists for them beyond a certain point. I recall
how much effort it took me to resist a forced “promotion”
into a management position at a former company—
I ended up staying a programmer, but was told that future
pay increases were pretty much out of the question if I
was unwilling to move into management.
There is also a belief that older programmers “lose
the edge” and don’t cut it anymore. That belief is mistaken,
in my opinion: older programmers may not burn
as much midnight oil as younger ones, but that’s not
because they are old, but because they get the job done
without having to stay up past midnight.
This loss of older programmers is unfortunate, particularly
when it comes to API design. While good API design
can be learned, there is no substitute for experience.
Many good APIs were created by programmers who had
to suffer under a bad one and then decided to redo the
job, but properly this time. It takes time and a healthy
dose of “once burned, twice shy” to gather the expertise
that is necessary to do better. Unfortunately, the industry
trend is to promote precisely its most experienced people
away from programming, just when they could put their
accumulated expertise to good use.
Another trend is for companies to promote their best
programmers to designer or system architect. Typically,
these programmers are farmed out to various projects as
consultants, with the aim of ensuring that the project
takes off on the right track and avoids mistakes it might
make without the wisdom of the consultants. The intent
of this practice is laudable, but the outcome is usually
sobering: because the consultants are so valuable, having
given their advice, they are moved to the next project
long before implementation is finished, let alone testing
and delivery. By the time the consultants have moved on,
any problems with their earlier sage advice are no longer
their problems, but the problems of a project they have
long since left behind. In other words, the consultants
never get to live through the consequences of their own
design decisions, which is a perfect way to breed them
into incompetence. The way to keep designers sharp and
honest is to make them eat their own dog food. Any pro-
ACM QUEUE May/June 2007 35