Are There Limits to Software Estimation?

Charles Connell submitted this analysis on software estimation, a topic which keeps coming up because it affects so many many programmers. Read this post about J.P. Lewis's earlier piece as well, if you'd like more background information.

Estimation time for projects

[TrollMan 5000]

Can be best based on these [sunspotcycle.com].

many factors in estimate

[neal n bob]

the number of anime festivals during the development time, what new PS2 games are soon to be released, whether there is a Magic: the gathering convention - all of these things affect the time needed for those smelly geeks in software dev to get off their butts and get the job done.

Reply coming right up...

[Baba Abhui]

I'm going to have a great reply to this important story. It's going to have all the latest stuff - it will be broken down into paragraphs and have a high degree of relevancy. My reply will be ready in two weeks, give or take a month or so, if the powers that be decide it also must contain links and be spelled correctly.

Re:Unless it's a simple project...

[batboy78]

Thats not the way CMM works, with a structured process you get things right the first time. I admit it is a huge pain in the butt. But it certainly increased our productivity, and scheduled releases. I beleive that there are only 2 Level 5 organizations in the US, NASA, and the ALC(Air Logistics Center?, at Ogden). And at level 5 they don't even need a testing organization to release mission critical applications.

Here's the formula I use...

[mrroot]

I figure out how much time it will take me to just sit down and do it without any interruptions.

Then I multiply that by the number of DBA's I have to go through to have a table get created for me divided by two.

Then I add to that the 10 times the number of project branches I need to request the PVCS administrator to create.

Then I count up the number of consultants sitting within 50 feet of my desk and multiply by that number times 20.

Then I multiply that number by the number of status reports I have to submit per week.

Finally, I add to that the number of games of foosball I play per day on average * 10.

That number is the final number of days it will take to complete the project.

Re:Unless it's a simple project...

[Mr. Fred Smoothie]

And at level 5 they don't even need a testing organization to release mission critical applications.

Maybe that explains their shift toward missions that don't cost as much and fail more often.

Rules of Software Estimation

[Jordy]

I typically use something like the following to counteract my instinctual response to undercut myself. I've found that because seperating work from home life is so difficult, not assuming I'll always have that time for the project makes it hard to make correct estimates.

Let x be the first number in days that pops into your head when you think about how long a project will take.

If the project requires you to work with someone else at any stage (including QA), let x = x*2.

If you usually work on weekends or after hours (or before hours in case of a flipped engineers schedule), let x = x*1.5.

If you are in a bad mood when the number of days pops into your head, you weren't really paying attention to what the project was or you simply aren't in the coding frame of mind, let x = x / 0.9.

If you haven't felt modest in the last 24 hours, let x = x * 1.2.

If the project requires any type of documentation, let x = x*1.2.

Wow, a /. first

[T1girl]

Somebody is actually concerned about not pissing off the customer? What next, tea and sympathy for the poor end-user?

Re:Of course there are limits.

[Anonymous Coward]

That's a remarkably arrogant statement.

Companies do not exist so you can write great software. Companies exist to make money, by definition. If a project is going to cost more than it will make, it is not worth doing.

I've watched (and sadly, contributed to) the demise of several companies directly because of this attitude you hold. Now, I work at a marketing-driven startup that's barely 4 months old, and is already wildly profitable. The key difference is that the engineer (me) understands that engineering concerns are a *distant* second to the pragmatic concerns of MAKING MONEY. I design software accordingly.

It isn't about the accountants and marketing people trying to "prove their usefulness", it's about them making the money to pay your salary and you would be wise to not forget that.