This is my personal blog and anything I write here in no way reflects the opinion of Cisco Systems, my employer. If it does, it is only by pure coincidence :) Nothing here constitutes investment advice either, so you can't sue me.

Jason in Real-Time

License

Fun Stuff

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions. NO MATERIAL HERE CONSTITUTES INVESTMENT ADVICE. The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are solely your responsibility.

How to estimate software delivery dates, and why Vista is late

I just read a fascinating post about the reasons for Microsoft Vista constantly missing its ship date. I suspect that there may be other reasons as a result of Ray Ozzie coming onboard midway through the process, as I'm sure there were a few bells and whistles such as Live integration that he demanded be in the final product, and it'll probably end up being a far better product as a result.

What's interesting, however, is that the post talks about the difficulty of accurately estimating software development times and the fear that developers and development managers have to tell their bosses that they simply don't know when it will be done. This is a topic I'm intimately familiar with :)

The problem is, I think, that people who have never written software themselves think of the development process as something like building a house. You put some boards here, screw them together, hang some drywall over here, nail in some shingles, buy some doors and windows and screw 'em in, and bam, you have yourself a new operating system. It doesn't work like that.

Most of the time, the process of writing software is more akin to solving a Rubiks cube: you know what needs to be done and how to do it, and you have a very rough idea of how long it will take you. Sometimes, in fact, it'll only take you a couple of minutes because you get lucky and try the right combination within the first few minutes. Most of the time, however, it's a process of trial and error, and you really don't know how long it's going to take. You could ship it early, but it's probably not going to have solid colors on all sides.

I know that this is the type of thing that makes project managers wake up in cold sweats since they deal in black and white, but software development is a very grey, fuzzy practice. What would you tell somebody who asked you how long it was going to take you to solve a Rubiks cube? I don't know what I would tell them, probably a year since I really have no idea. It's pretty much the same with estimating software delivery dates.

What a typical software developer will give you is a timeframe for how long they think it will take them if about half of everything goes right. Experienced developers will pad their estimate somewhat, young developers will tell you tomorrow because they don't know all the different things that can impact the timeline. The project manager needs to take these dates and run them through a reality filter, doubling the estimate if he wants to be accurate or ahead of schedule. Did you hear that, project managers? :) Double every estimate a developer gives you, because he usually does not know how long it will take him. If you do that, all of your projects will be on time.

Business owners need to understand this process somewhat so they can deal with customers and delivery dates. I know it sucks, but you can't make somebody solve a puzzle faster by telling them you need it yesterday. There's just nothing you can do. And if you're up against a tight deadline it doesn't typically help to bring in more puzzle-solvers since it takes so long to get them up to speed. Imagine if each Rubiks cube had different pictures on each side that you have to put together, and the picture doesn't exist anywhere except in the puzzle-solver's head. Trying to bring somebody else in means that the developer has to explain the end-vision and try to catch the other person up on where they're at in the puzzle-solving process. It's very time-consuming.

If you're in the software business, you know what I'm talking about. It sucks and it's not fair, but you made the choice to be in this business so it's up to you to decide how to handle it.

Comments

How to estimate software delivery dates, and why Vista is late

I just read a fascinating post about the reasons for Microsoft Vista constantly missing its ship date. I suspect that there may be other reasons as a result of Ray Ozzie coming onboard midway through the process, as I'm sure there were a few bells and whistles such as Live integration that he demanded be in the final product, and it'll probably end up being a far better product as a result.

What's interesting, however, is that the post talks about the difficulty of accurately estimating software development times and the fear that developers and development managers have to tell their bosses that they simply don't know when it will be done. This is a topic I'm intimately familiar with :)

The problem is, I think, that people who have never written software themselves think of the development process as something like building a house. You put some boards here, screw them together, hang some drywall over here, nail in some shingles, buy some doors and windows and screw 'em in, and bam, you have yourself a new operating system. It doesn't work like that.

Most of the time, the process of writing software is more akin to solving a Rubiks cube: you know what needs to be done and how to do it, and you have a very rough idea of how long it will take you. Sometimes, in fact, it'll only take you a couple of minutes because you get lucky and try the right combination within the first few minutes. Most of the time, however, it's a process of trial and error, and you really don't know how long it's going to take. You could ship it early, but it's probably not going to have solid colors on all sides.

I know that this is the type of thing that makes project managers wake up in cold sweats since they deal in black and white, but software development is a very grey, fuzzy practice. What would you tell somebody who asked you how long it was going to take you to solve a Rubiks cube? I don't know what I would tell them, probably a year since I really have no idea. It's pretty much the same with estimating software delivery dates.

What a typical software developer will give you is a timeframe for how long they think it will take them if about half of everything goes right. Experienced developers will pad their estimate somewhat, young developers will tell you tomorrow because they don't know all the different things that can impact the timeline. The project manager needs to take these dates and run them through a reality filter, doubling the estimate if he wants to be accurate or ahead of schedule. Did you hear that, project managers? :) Double every estimate a developer gives you, because he usually does not know how long it will take him. If you do that, all of your projects will be on time.

Business owners need to understand this process somewhat so they can deal with customers and delivery dates. I know it sucks, but you can't make somebody solve a puzzle faster by telling them you need it yesterday. There's just nothing you can do. And if you're up against a tight deadline it doesn't typically help to bring in more puzzle-solvers since it takes so long to get them up to speed. Imagine if each Rubiks cube had different pictures on each side that you have to put together, and the picture doesn't exist anywhere except in the puzzle-solver's head. Trying to bring somebody else in means that the developer has to explain the end-vision and try to catch the other person up on where they're at in the puzzle-solving process. It's very time-consuming.

If you're in the software business, you know what I'm talking about. It sucks and it's not fair, but you made the choice to be in this business so it's up to you to decide how to handle it.