|
If
you want to know when new interviews go online,
subscribe to the WebWord.com
Usability Newsletter!
Painless
Software Management
An interview with
Joel Spolsky, the wizard behind Joel
on Software.
Conducted via email by John S. Rhodes
(15-August-2001)
The Basics
What is
software development?
Well, it ain't
what you thought it was in college, when your professors taught you about
making loops and objects. That's a part of it, but if your software is going
to be popular, you are going to have to deal with a million other things:
writing manuals, creating good looking icons if you have a GUI, testing,
recruiting good programmers, making a product that people want, usability
testing, dealing with Norman the Cranky Tester, and about 100 other things
that take up most of your time.
What is the software development life cycle? Is it outdated? How do you
manage software projects? What are some of the key principles?
The traditional
model was called the waterfall model: you write a specification, then a
technical design, then write some code, then test it internally, then beta
test it, then ship it, then start all over. We'll call that The Old Way.
There are a lot of people who think that you should be basically doing all
of those things at the same time, sending your customers a new build every
week and changing things whenever. More responsive, right? Well, I've seen
teams that do it The Old Way and teams that do it The New Way. And the
single common denominator of New Way teams is perpetual chaos. I've seen
companies that released software every Thursday. They were so bogged down in
dealing with the details of every release, version management, and dealing
with customer problems that they simply had no time left to write any new
code. Everything was fire-fighting. And they were addicted to this cycle, so
they couldn't IMAGINE doing, say, monthly releases instead of weekly.
In your opinion, what does the software landscape look like? Put another
way, how do you categorize and classify the various types of software?
There are several
major kinds of software. There's fun hobby software that you wrote at home
or for a programming class. There's traditional "shrink-wrap"
software which sells for, say, $10 - $1000 and is used by thousands or
millions of people -- that's what I understand best and what I focus on with
"Joel on Software". There's "enterprise software" which
is usually a lot simpler and stupider than typical shrinkwrap software,
costs $1,000,000, and requires an army of consultants to get it working. And
finally there's internal "IT/MIS" software that is created
internally in organizations to solve their specific needs. Each of these
categories requires very different skills: hobbyists only have to do about
1/10th of the work it would take to get the same functionality in
shrink-wrap, which always surprises young software companies founded by CS
students.
Bugs!
What are
software bugs? How do programmers find them? How do programmers deal with
them?
Hmm. That's a
difficult question. Suffice it to say that anything that doesn't behave as
designed is a bug. Finding and dealing with bugs is a whole discipline in
itself.
What is the difference between a bug and a feature?
There is no
difference :) It's important to remember that a bug and an unimplemented
feature are really the same thing: they are both "to dos"
competing for limited developer time. One of the reason people ship
"bugs" knowingly is because the bugs are less severe than
the absence of the features would be. If Microsoft Word crashes on you once
every three months, that is probably not as bad as if it did not have the
ability to spell-check your document. (And don't forget -- shipping is a
feature! A big one!)
In general, as the complexity of software increases, more bugs are
generated. Most users want simple, easy-to-use software so why do
programmers and companies feel the need to increase the complexity of
software? Is it all about satisfying egos and pushing upgrades?
Rubbish. Those
assumptions are flawed. It is not true that most people want simple
software. They want easy-to-use software, I agree. Companies add features
because some customers want them. Not every customer wants every feature:
most customers use 20% of the features. This leads many naive startups to
think they can deliver a product with 20% of the features and still capture
the market. Then they crash and burn when they discover that actually
everybody is using a different 20% subset of the features of the
market leader.
My favorite story
is about the various alternative "simple" word processors which
small companies have shipped over the years. "You don't need all those
complex features in Word!" they said, and it sounded right. They took
pride in leaving out the word-counting feature. What did the reviewers do?
They tried to write their review using NotQuiteWord 1.0 itself. And every
journalist works on a strict word count quota. So every single review of one
of these "simple" word processors always says, "gosh, it
doesn't have word-count. I couldn't use this. But you should!" Then
everybody else will have some other reason they can't use it -- maybe it's
just that they need to collaborate with someone and therefore they need a
word processor that supports 100% of the Word file format without loss of
fidelity.
More complexity
does not have to mean more bugs. Windows 2000 is the most complex product
I've ever used regularly and it is also the most stable. The same is true of
Linux, Emacs, GCC, Microsoft Excel, and the software which runs the Boeing
777.
People Are People
In your mind,
what is usability? What does it mean to you as a programmer, project
manager, and writer?
Usability means
that the program behaves the way the user expected it to behave. Everything
any usability guru tells you is a corollary of that axiom. As a programmer,
I think about creating products that mentally represent what the user
expects them to do, and where they can't, I focus on making programs which
do a good job of explaining themselves -- through metaphors, through helpful
text, through good screen layout, etc. As a writer, I put myself inside the
reader's head and try to imagine what they want to know next.
While I don't expect Groups Hugs and Kumbaya, I think it is interesting
that project teams often have a tough time getting along. Why do
programmers, designers, and usability folks clash so often?
Mostly because
they have different vocabularies and assumptions. Programmers, in
particular, have a particularly rigorous way of thinking which seems
inflexible and obnoxious to non-programmers. And they're usually very
analytical and tend to look down on people who can't (or don't) code. Alan
Cooper gives a great example of this: the programmer who says, "I
answered the question you asked. You just didn't ask the right
question." So for example the designer asks the programmer if he ate
lunch, and the programmer says, "Yes, yesterday. And the day before.
And the day before that." He thinks he's being super logical and the
designer just thinks he's a freak.
Why is it so hard to find people who can write code and still think of
their users? Is it just a matter of personality and ego, or is it something
more?
Not enough
training, I think. Everyone should read my book and this problem will go
away :) Alternately, force programmers to sit through several usability
tests, and they will become much more sympathetic.
Joel on Joel
Who are you?
What is your background?
That's a hard
question. Professionally, I like to work on software products that millions
of people will use. I worked on Excel, Juno, and I wrote the application
server used by MTV.com, Comedy Central, Blockbuster, and a lot of other
high-volume Viacom web sites.
What is Fog Creek?
Fog
Creek is an attempt to build a software company that will be every
developer's #1 choice of place to work. We focus on things like quality of
life, long vacations, plush private offices, great tools, exciting projects,
etc. Over the long run, the goal is to have an elite team of superstar
software developers, designers, and marketers that can create the next
generation of software that changes the world.
Over the short
run, last year was probably not the best year in history to start a company.
Fog Creek is focused on growing slowly and carefully and staying profitable.
So we're still a tiny company with one product shipping and one more in the
oven.
Your book, User
Interface Design for Programmers, is selling well at Amazon. Could you
tell us more about it? What are some of the key points? Don't be bashful,
why should people fork over money for it?
Remember how we
were talking about different people having different languages? Well, this
book is an attempt to explain how to make good user interfaces in a simple,
logical, and entertaining way that will appeal to software developers who
used to think there was something mystical or "artistic" about
good UI. The most common feedback I've heard is "it's not just for
programmers!" and that's true -- in fact I avoid anything too technical
and am pleased to say that my mother, an English professor, read it, which
is more than I did for her books on literary theory.
Editor's Comments
(1) I've been
reading the Joel on Software
weblog for a long time. Be sure to check it out and be sure to subscribe to
Joel's site to get updates when he posts news.
(2) Don't hesitate
to get a copy of Joel's User
Interface Design for Programmers. It is a great book. If you are not
convinced, check out the online
version.
-- John S.
Rhodes
What next?
|