"Make Better Software: Schedules"

Uploaded by FogCreekSoftware on 01.02.2010

We were really running out of space in the old office,
so we had to scurry to find a new office space downtown.The space, as usual, in New York,
is either delivered in terrible condition, or completely empty,
and so, the landlord had offered to pay most of the costs of renovating it,
and building offices, and so forth. And so, we've been doing this construction
project, and dealing with deadlines, and completion,
and estimates, and all those things. How do you think this project compares
to actually doing, writing software?Well, it's very, very different
when you try to schedule it. So, for example, our construction manager,
Kristin, has built offices before, and she's managed
this project many, many times n this very building
with these very workers. And for her, building some drywall with a
sidelight in it or putting in drop ceilings
is something she's done a million times, and she knows how long it takes.
And when she says it's going to take two weeks, that's because she's done it before
and it took two weeks the first time, and it took two weeks the second time,
and it took two weeks the third time. When you're building software,
you're never doing the same thing again that you've done before, because if you were,
you would just reuse that old code. Software is not building.
It's not construction. It's design. And design is like exploring a space of possibilities
and what all the possibilities are, and you don't know how long it's going to
take. It's like science. You don't know how long
it's going to be until you find your solution.
So, software projects are very, very different to schedule,
because there are so many unknowns that you should never see in a construction
project unless you're doing something really wacky
and unusual. Before you do any new work on a software,
whether you create a software product or a new software feature,
any kind of programming work, you really have to do a cost benefit analysis.
You have to figure out, is it going to be worth the amount of effort
that we're going to put into it? Can we make our money back?
Is this the best way to spend the next three months,
or are there some other things that we could do
that would have a lot more bang for the buck, as they say?
And the only way to correctly make these kinds of analyses
is to come up with some kind of a schedule and an estimate of how long it's going to
actually take to add a feature, or to build a software product.
So, schedules are essential, really, to making the right decisions.
Figuring out how much time a certain thing is going to take
is essential to deciding what things to do and to making the right decisions about those
things. And then once you have a schedule,
keeping on schedule is really important or using the schedule kind of as a tool to--
is really important, because that gives you a constant imperative
to remove useless junk; otherwise, there's a real tendency
to add a lot of useless junk to your software, a lot of features that aren't really going
to be important, that seemed cool at the time, but may not
be that important, what we call gold plating.
And if you're really trying desperately to meet a schedule,
and you're like every other software development team
in the history of the world, then you're constantly slipping.
And when you're trying to keep on a particular date,
you have a schedule as a tool, you can say, "Oops, we just slipped.
We're going to have to cut a little feature," and you can search through that list of 24
things that you're going to do, and find the one
that just doesn't really maybe absolutely have to be
in the final product, and get rid of that. And through this constant elimination of not
great ideas, you wind up making a better product.