Typical Software Estimation

Me, “What is the biggest software project that you have ever worked on?”

Typical response, “20,000 hours!”

Me, “Wait.  I did not ask how long it took, I asked how big.

Typical response, “$2 million dollars.”

Me, “Is my question vague did you not understand me.  I asked how big.”

Typical response, “What?”

Me, “How big?”

Typical response, “What?”

Me, “Okay, we are not getting anywhere.  Let me try another approach.  How big is your house?”

Typical response, “2,000 square feet.”

Me, “Good. You understand the question.  You just gave me a unit of measure of size.  So what is the biggest software project that you have worked on?”

Typical response, “20,000 hours.”

Me, “We seem to be back at square one.  Let me try another approach, how much was your house and how long did it take to build?”

Typical response, “$250,000 dollars and about 6 months.”

Me, “$250,000 dollars is a cost measure and 6 months is a time measure.  Get it.”

Typical response, “I think so?”

Let’s try again, “What is the biggest software project that you have worked on?”

Typical response, “About 42 people worked on the project?”

Me, “I feel like I am getting nowhere because I did not ask how many people worked on the project. I am not asking how many people, how many hours or how much it cost, I am asking how big.”

Typical response, “I don’t know.”

Me, “The past is the best indicator of the future.  Your estimates needs to be based upon past performance.”

Typical Response, “Wow, that is deep.  How do I proceed.”

Me, “It is not that hard.  Determine the average size  and average cost of a few past software projects in function points.  This gives you historical dollars per function points.  If you determine the number of function points for a new project, then you can easily determine the cost.”  The cost is number of function points for your new project x historical cost per function point equals total cost.

Typical response, “I don’t have time to do all that because I need to start coding.”

Me, “Typical.”


How much is that doggie in the window (arf! arf!)?

Asking what is the average cost of software development is equivalent to asking how much is the cost of the average dog.  The software industry is horrid at estimating and not good at asking questions either.   There is no magic to estimating software projects because the past is the best indicator of future performance.    The problem is most software organizations do not want to spend anytime at all gathering historical data or determining the size of its software projects (arf! arf!).

There is no such thing as an industry average for software development (roof! roof!)  There is no industry average for construction or manufacturing either.  Construction costs depend on whether the structure is residential or commercial and it depends if the structure is a retail center, office complex, a warehouse, so on and so forth.  One of the main ingredients in determining construction costs is the size of the structure.

The size of the software project is the largest factor in determining the cost.  Most software organizations just skip this step and decide they will figure it out as they go along.  The industry sector is a another driving factor.  Yes, the industry (arf! arf!).   Software costs are not constant across industries.  The cost to develop software for the healthcare industry is different than the insurance industry.  The cost for a dental office is not the same as the cost for real estate office.


Software development organizations have no historical data to use  for estimating future projects.

Software development organizations have no idea, none whatsoever, of the size of its projects.

In the end most software developers just skip the two most important ingredients in estimating and just make up some number.   No wonder the software industry is horrid at estimating (roof! roof!).

So how much is that doggie in the window?  It depends on the type of dog and if it has a waggley tail (arf!, arf!)



Ancient Wisdom for Software Estimating

There is a lot of ancient wisdom that is useful for software development. Some of the wisdom comes from the West and some from the East. One of the most interesting parables can be found in the Christian New Testament. Jesus was addressing a crowd of onlookers and told this story. The story can be found in Luke and it reads, “Which of you wishing to construct a tower does not first sit down and calculate the cost to see if there is enough for its completion? Otherwise, after laying the foundation and finding himself unable to finish the work the onlookers should laugh at him and say, ‘This one began to build but did not have the resources to finish’. Luke 14:25-33

Too many software projects start without a clear understanding of the functionality of the project  or total project costs. The project sponsor marches his or her team straight down the path of project disaster. They ignore all the warning signs. The problem is that they did not know the amount of resources needed to finish the project in the first place. They did not fully understand the total cost or total effort.

Too many software developers do not know how tall the tower is going to be  or how much functionality is required.  In the end failing to understand total project cost and effort is not a new idea. It is just an accepted practice in the field of software development and especially in software estimating.

Reboot! Some Metrics

Since publishing my online book  Reboot! Rethinking and Restarting Software Development in earlier February 2009 there has been 35,000 pages read by 4,000 different visitors in 101 different countries.

The USA and India had the most visitors with about 1,000 visitors each followed by United Kingdom (250) and Canada (153).  What I find interesting are not the number of readers from countries known for software development, but the readers from countries such as Nepal, Moldova, or Zambia.   There were even a few readers from the Cayman Islands.  They need to step away from the laptop and get back to the beach!


Published in: on March 24, 2009 at 23:01  Leave a Comment  
Tags: , ,

How do you write great user manual, you don’t.

A user manual is created to provide step-by-step instructions on how to use a product. The product can be a lawn mower, iphone or a software application. Software applications that are designed well do not require any user manual. Instead the software application is designed to be intuitive.

To design something that is intuitive requires a great understanding of how the product fits into the natural flow of things. This means the person or group of people that will use the software application have to be studied.  Too many software applications require the user to adapt instead of developing a software application to the user’s natural environment.

It does not matter if we are talking about people or gorillas. It is best to study people in their natural habitat instead of dragging them into a conference room and asking, “What do you want?” It is always best to go to the jungle and study your customer.  Ethnological analysis, going to the jungle, is alien in software development.  Most software developers have little or no contact with an actual user.

If you don’t understand how a person does his or her daily tasks or the natural workflow, then you can’t design software applications that are intuitive. Let me guess – you don’t have time to go to the jungle because you are busy writing user manuals and other documentation.


My mobile phone rings, so I give a typical, “hello, this is David Longstreet.” There is no “good morning, my name is…, how are you”, but the voice gets right to the point. The voice on the other end asks, “What is the average cost to develop software?” Without hesitation I respond,”42!”

There is a long pause and the voice asks, “42 what?”

I say, “42 whatever you want, you fill in the units.”

The voice, “What do you mean?”

I respond, “42 hours, 42, 000 dollars, 4,200 euros, 42 million whatever works best for you.”

The voice, “Wow, I like this. I think I will go with 42,000 hours.”

I say, “Sounds good to me.” There is a long pause, so I assume the voice is thinking.

The voice asks, “how many people?”

Quickly I respond, “42”

The voice, “How many months?”

In a rapid fire fashion I say, “42”

The voices says, “42,000 hours, 42 people, 42 months.”

I say, “I think you got it!”

The voice says, “I really want to thank you for helping me out on this.”

I gleefully respond, “No problem.”

The voice just hangs up. There is no typical good bye, just silence on the other end of the phone. I think to myself, “42, it is really the answer to all the questions of the universe.”

Software Paleontologist: New Job Titles for the Software Industry

Software Psychologist – help software organizations over come its fears and phobias

Software Psychiatrist – same as a software psychologist but they prescribe drugs.

Software Archeologist –dig around looking for project artifacts.

Software Paleontologist – dig around for looking for evidence the project actually existed.  They also theorize what killed projects.

Software Theologist – pray for project success.

Software Plumber – unclog software projects.  This is not a glamorous job and it requires cleaning the project toilet.

Software Janitor –pick up after everyone else.

Software CSI – study the forensic evidence to determine if a project was murdered or committed suicide.  By the way most projects commit suicide.

Software Entomologist – collect all types of bugs found during the project.

Software Zoologist – studies all kinds of animals that work on software projects

Software Tap Dancer – dances around difficult project issues