Software Estimation

In his latest post on software estimation, Mike Nichols says "Software estimation has been one of these quandaries for me mostly because of my lack of experience."  I couldn't agree more.  I only hope software estimation will be easier the longer I'm in the business.  He goes on to say that his boss has certain expectations about estimates because he is used to estimates from his (civil?) engineers being complete and accurate.

This made me wonder how similar the estimation process is for building a skyscraper vs. building an ERP?  Or building a bridge vs. building a shopping cart.  Since I know zero about civil engineering I will commence with the presumptions.  I presume that if I presented a bid to build a skyscraper using Agile methodologies I would be laughed out of the room.  "Yes, it will take us three weeks to pour the foundation, then we will meet again to talk about how long it will take to complete the parking garage."  I think the reason why the two processes cannot be considered even remotely similar is this:  It's pretty hard to refactor concrete, rebar, and I-beams and there's no such thing as a v2.  The design has to be right the first time.  I don't think the most senior architects at Microsoft, Oracle, or EDS can guarantee they will get it right the first time.  The skyscraper customer is aware of this also.  If I came to my skyscraper engineer in the last phase of the project and told him "I want to add another 25,000 square feet to the parking garage, I have to have this, this is a deal breaker for me", he would laugh me out of the room.  So why do software customers think they can do that to us? 

I think the software industry needs something to help lend a physical aspect to software systems.  If customers understood that software project Z had the equivalent physical representation of ten skyscrapers, six months into the project the would understand why it is unfeasible to even request changes to certain parts of the system.

Perhaps that is why Selling agile is hard, if not impossible.  People that aren't in the software business are used to hearing estimates from their mechanic, or general contractor, or plumber.  And those estimates invariably say the task will be done in X number of days for Y cost.  They understand the process enough to know not to even ask if it's too late to add a basement to the house after the foundation is poured.

posted @ Sunday, March 11, 2007 6:35 PM


Print

Comments on this entry:

# re: Software Estimation

Left by Willie Tilton at 6/20/2007 10:18 PM
Gravatar

I think the best thing to do is to gain experience by first writing out all of the requirements, break it down into things that are easier to quantify. Like: The system shall have a button on the front page. <br /><br />We know that that should take a few minutes, so give yourself padding and do the same for the rest of the requirements.<br /><br />Once you know how long a certain "block" of code takes to create you'll be able to more generally figure out how much time it takes to build those big pieces. Until then you have to break it down into simple stuff and then add it all up.<br /><br />I'm sure that people don't just go out and say...well we need a bridge...lets estimate the time to do that by just thinking about the bridge. No, they estimate the cost of logistical time to get the components, hiring the manpower, laying down foundations, acquiring the equipment, and so on.

# re: Software Estimation

Left by Willie Tilton at 6/20/2007 10:20 PM
Gravatar

Oh, and why do they assume that software creep is ok? Because foolish developers, LET THEM!<br /><br />I've been beaten many times by someone under bidding a software project because they way understimate the cost of building it, and charge way less. They're the ones staying up till all hours of the night though, so I don't mind too much.

# re: Software Estimation

Left by Willie Tilton at 6/20/2007 10:21 PM
Gravatar

Oh, and one last thing :)<br /><br />Fixed price contracts are the super devil. You sign one, you're not getting paid the way you should. Just say, "Never again".

# re: Software Estimation

Left by hammett at 3/11/2007 8:20 PM
Gravatar

I understand you, but you're going against what XP preaches "Embrace change". That's in fact the whole point about XP:<br /><br />- having test to give you confidence<br />- having the simplest thing that could possibly work<br />- having no code ownership...<br /><br />In the end the goal is just make changes not impossible.

Your comment:



 (will not be displayed)


 
 
 
Please add 8 and 6 and type the answer here:
 

Live Comment Preview:

 
«August»
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456