I wrote an article about the method we use at Fog Creek for making software schedules which I've seen work very precisely, consistently, on projects from a week to two years.
The basic approach is to make sure that the granularity of the tasks that you are estimating is fine. If you itemize the tasks at the procedure level (write subroutine x), where each task is less than 2 days, your schedule will work. The reason most people's estimates don't work is because they pull them out of the air, instead of actually thinking about what tasks they will need to complete. Getting down to the procedure level forces you to figure out what you're actually going to do, which is how you get a real estimate.
Let me tell you a bit about the context of everything that I write at
Joel On Software. Everything I say should only be taken as advice if your goal is
to write (a) commercial (b) software (c) for lots of people that (d) succeeds, or at least
has a pretty good chance of it. I run a tiny software company, Fog Creek Software,
in a niche where Microsoft has (at least) two competing products. I'm
not any happier about Microsoft's dominance than anyone else. I don't
own Microsoft stock. On the other hand, I try to be as rational,
logical, and non-religious about every decision I make because
it's the only chance I have of succeeding.
Yes, it's true. If you make a major mistake, you get killed, often
by Microsoft. Some people think it's a pretty sad state. I just think
it's capitalism and evolution. Dodo birds are extinct, and so is
Visicalc. I don't want to be extinct, so I try to learn from the mistakes
of the companies that have tried to go up against Microsoft. It's easy
for me because I was inside and I know something about the way R&D worked
at Microsoft. I've tried to share many of these lessons on my site.
To succeed in commercial software you have to get beyond being shrill and
angry about Microsoft. You have to be cool headed and
smart and study the past and make the right decisions for your company,
not the right decisions for some arbitrary sense of aesthetics
(although of course I am as big a fan of clean documented code as anyone.)
Production code is not so pretty. Open source code is not so pretty.
No real code is all that pretty. It takes time to study it, understand it,
and read it, to understand how it got the way it is. The more widely the
code is used, the more true that is. For Fog Creek's latest software
product, CityDesk, we stayed up one
night tracking down a bug that only
happened on Chinese Windows, where asc(chr(x)) turned out not to be equal
to x, an assumption we had been making. How many of you ever thought about
getting your code to work on Chinese Windows? No matter how well that piece
of code was designed, I'm sorry, I've been programming for 20 years and I
never realized that asc(chr(x)) was not always equal to x on some platforms,
and I designed it wrong, and until someone tried it on Chinese Windows, I never
would have known. Now the code uses byte arrays instead of strings and doesn't
have that problem. There's a nice comment in the code saying "use byte arrays
instead of strings because of MBCS versions of Windows." The code now works
perfectly, but the byte arrays are a little bit uglier than strings. If ten
years from now somebody rewrites CityDesk from scratch, I'll guarantee
you that 95% of the Windows programmers working today would make the same mistake
again, and stay up all night again.
If a piece of your code is ugly and doesn't work, by all means,
rewrite that piece. If it's ugly and
works perfectly, you're wasting valuable hours rewriting it, time that could
be spent doing something that will gain you market share. If you really have
an undecipherable mess of spaghetti, 9 times out of 10 you're just being
lazy about deciphering it because it seems like more fun to create it from
scratch, but it's the ultimate in arrogance to think that your newly created
from-scratch version is going to be all that great.
Slashdot Mirror
I wrote an article about the method we use at Fog Creek for making software schedules which I've seen work very precisely, consistently, on projects from a week to two years. The basic approach is to make sure that the granularity of the tasks that you are estimating is fine. If you itemize the tasks at the procedure level (write subroutine x), where each task is less than 2 days, your schedule will work. The reason most people's estimates don't work is because they pull them out of the air, instead of actually thinking about what tasks they will need to complete. Getting down to the procedure level forces you to figure out what you're actually going to do, which is how you get a real estimate.
Lacking a PGP key, I'll have to direct you to look on Joel's homepage. Am I really THAT famous?
Yes, it's true. If you make a major mistake, you get killed, often by Microsoft. Some people think it's a pretty sad state. I just think it's capitalism and evolution. Dodo birds are extinct, and so is Visicalc. I don't want to be extinct, so I try to learn from the mistakes of the companies that have tried to go up against Microsoft. It's easy for me because I was inside and I know something about the way R&D worked at Microsoft. I've tried to share many of these lessons on my site.
To succeed in commercial software you have to get beyond being shrill and angry about Microsoft. You have to be cool headed and smart and study the past and make the right decisions for your company, not the right decisions for some arbitrary sense of aesthetics (although of course I am as big a fan of clean documented code as anyone.)
Production code is not so pretty. Open source code is not so pretty. No real code is all that pretty. It takes time to study it, understand it, and read it, to understand how it got the way it is. The more widely the code is used, the more true that is. For Fog Creek's latest software product, CityDesk, we stayed up one night tracking down a bug that only happened on Chinese Windows, where asc(chr(x)) turned out not to be equal to x, an assumption we had been making. How many of you ever thought about getting your code to work on Chinese Windows? No matter how well that piece of code was designed, I'm sorry, I've been programming for 20 years and I never realized that asc(chr(x)) was not always equal to x on some platforms, and I designed it wrong, and until someone tried it on Chinese Windows, I never would have known. Now the code uses byte arrays instead of strings and doesn't have that problem. There's a nice comment in the code saying "use byte arrays instead of strings because of MBCS versions of Windows." The code now works perfectly, but the byte arrays are a little bit uglier than strings. If ten years from now somebody rewrites CityDesk from scratch, I'll guarantee you that 95% of the Windows programmers working today would make the same mistake again, and stay up all night again.
If a piece of your code is ugly and doesn't work, by all means, rewrite that piece. If it's ugly and works perfectly, you're wasting valuable hours rewriting it, time that could be spent doing something that will gain you market share. If you really have an undecipherable mess of spaghetti, 9 times out of 10 you're just being lazy about deciphering it because it seems like more fun to create it from scratch, but it's the ultimate in arrogance to think that your newly created from-scratch version is going to be all that great.