Interview for Joel on Software Live
      Michael Smith: This time we are talking with Joel Spolsky about his
CFUNITED-05 talk "Project Management the /Joel on Software/ way". So why
should a developer come to your session Joel?

Joel Spolsky: Most people who have to manage software projects are software
developers, not project managers, and nothing about writing code has trained
them to put together large projects and ensure that they actually deliver a
quality product on time. I’ll use this session to introduce my own simple
philosophy of project management: running a team, picking the features to do
first and the bugs to fix first, and deciding when to ship.

MS: So what kinds of things can happen when an untrained project manager
runs a software project?

JS: All kinds of things. A common mistake is to hope, against all evidence,
that the team members are smart and will be able to organize themselves, so
the newly promoted programmer decides he or she can afford to spend 80% of
their time writing code and only 20% of their time managing. The trouble is
that without any kind of system in place to decide what to do and in what
order, chaos ensues and you either get a death march project that’s never
done, or an inadequate product that nobody wants. A typical manifestation of
this is that team members work on the fun things first, not the important
things, so when the schedule is running late and you have to cut features
all the features left to do are important features that can’t possibly be

MS: Ouch that sounds painful! So how do you think the team should be run?

JS: I would never have the chutzpa to say that I have the answer for all
teams. However, in most cases, the key thing is to have a
constantly-updated, real-time, highly detailed list of features and tasks,
with priorities and estimates for each item. Then at any time everybody
knows what they should be working on and in what order, and if you have good
estimates, you should be able to say "if we do all priority 1 features,
we'll finish on date X, and if we also do priority 2 features, we'll finish
on date Y." Now it's a simple matter of setting a date that gets the optimal
balance of features and shipping (shipping is a very valuable feature).

MS: What about bugs - software always seems to ship with bugs - can that be

JS: For the purpose of project management, a bug and a feature are the same
thing: something somebody has to spend some amount of time on with some
priority. If you can store feature requests and development tasks in your
bug tracking system, all the better, because now every morning every
developer knows exactly what to work on first.

MS: Doesn't tracking bugs and tasks add a lot of overhead to the project?

JS: Yeah, and hiring an architect adds a lot of overhead to your kitchen
renovation, but they both save you a lot of time and money, in the short run
and in the long run! You're going to be tracking bugs and tasks anyway, it's
just a question of whether you do it in an organized fashion where everyone
can be on the same page, or on a whiteboard in one person's office, where
it's apt to be erased by the cleaning lady.

MS: What about dependencies between tasks - especially things the client is
delivering to the team. Any comments on how you handle that?

JS: My experience is that when building software you don't have as many
dependencies as you might think. In house building, you really have to build
the walls before you can put in furniture, or it will rain and ruin the
furniture. But in software the furniture programmer can just write "int
wall(){return 43;}" as a placeholder and get all his furniture in place long
before the wall guy has delivered his piece. Its so easy to move things
around that you hardly have any dependencies, and those you do have are so
clear and obvious it's almost not worth tracking them formally.

MS: How do you estimate when the project will be completed?

JS: Begging forgiveness in advance for a glib answer, you don't! What you do
is set the date when the project has to be completed and then pick the
optimal set of features to meet that date. Your schedule should have line
items and estimate for every task, bug fix, and big line items for
debugging, integration, buffer for new features that you forgot to mention,
even line items for vacations and holidays. Then you can add up the number
of hours you have for each person on the team, take the maximum of that, add
it to today's date, and get your scheduled completion date, which,
inevitably, will be two years too late. So then you start prioritizing and
re-prioritizing until you can reach the date you have to ship on with only
the top priority features.

MS: Sounds good. See you at CFUNITED.
Home  |  About  |  Topics  |  Speakers  |  Exhibitors  |  Register  |  News  |  Travel
© Copyright TeraTech Inc 2004. All rights Reserved.