What is the average cost to develop software — It depends

I get asked the question, “What is the average cost of develop software?” all the time.  The answer it depends.

1.  When people ask the average what they are asking is what is the average unit cost of software.  This is a similar question to what is the average cost per square foot of construction.  I use function points, so the question becomes what is the average cost per function point to develop software.    The average dollars per function point is one way to determine the average dollars per unit of software developed.

2. The average cost per unit of software developed depends on several factors.

2a.  The type of business the software supports.  The unit cost of software is going to be different for insurance industry and the aerospace industry.  The same is true with construction.  The average cost per square foot  to build a mission control building for NASA is not going to be the same as the cost per square foot to build an insurance office building.

2b.  Location, Location, Location.  Like real estate the cost per unit of software is going to depend on where it is built.  If the software is built with cheap labor (the main input), then the cost will be less.  Of course it depends if the cheap labor is of equal productivity.  If the cheap labor is half the cost and half as good, then you really do not gain anything from using cheap labor.

2c. Duration.  The duration impacts cost too.  Not only development costs but maintenance costs.  If the the software has to be developed as soon as possible it is going to be expensive per unit.

Actually there are about 50 other factors that impact cost, but these are three big ones.

Read more at Reboot! Rethinking and Restarting Software Development.

Advertisements

IT the toilet that never stops flushing

I was consulting for a large international firm and one of the executives on the business side made the comment that, “IT is the Toilet that never stops Flushing.” To often this is an accurate phrase to describe how money is spent in IT. Most of us have had a running toilet in our bathrooms and it can be very annoying. In the end a running toilet is just money down the drain and too often spending money on IT is money down the toilet too.

Over the past 20 years a lot of IT spending was done without careful cost benefit analysis.  Too many projects were undertaken because there was a desire to move to the latest and greatest technology.  The current recession is causing IT to really justify its spending.   The business is forcing IT to wiggle the handle to see if they can’t stop the water from running.

Even though the current fade de jour is build as you go or ad hoc software development it is an expensive proposition.  Those IT organizations that embrace, study, and learn  the core business are the same organizations with the highest productivity rates, best quality and lowest costs per unit.

Read more at Reboot! Rethinking and Restarting Software Development

TPS Reports and Cover Sheets

Too often people are asked to record their time or report data and are clueless the reason.   They start thinking, “what’s the

initech

initech

point?”  They think of the ole, “IniTech – T.P.S. report” from the movie Office Space (TPS Time Sheets & Cover Sheet).

When people see how the data is being used, the value, “what’s in it for me”, then they are more likely to input data correctly and sometimes enthusiastically.

When I develop metrics for an organization, I have to rely on the quality of time sheets. Often people tell me the time sheet data is no good. If I am building estimating models based upon past data and the data is no good, then, the estimating model is going to be wrong too! I have to make a lot of adjustments to the historical data. Knowing how people spend their time on past projects is an invaluable management tool when planning for future projects. When projects are planned properly there is less chaos and often less overtime. Overtime is often the result of poor planning and poor estimating.

Read more at Reboot! Rethinking and Restating Software Development.

TPS Initech Time Sheets

Published in: on July 20, 2009 at 23:01  Comments (1)  
Tags: ,

What gets rewarded gets repeated!

A behavior followed by a reinforcing stimulus results in an increased probability of that behavior occurring in the future. – B.F. Skinner, Psychologist

The idea of “what gets measured gets done” is only partially correct.  It would be more correct to say, “what gets rewarded gets repeated.”  One of the most thoroughly accepted notions in psychology is the principle that behavior eventually extinguishes if it is not followed by reward.

I was on an airplane and in front of me was a father and his young daughter (she was about 3 years old).  When it came time to take off the father worked and forced his daughter to sit down in her seat with her safety belt fastened.  The child screamed and yelled.  The child wanted out of her seat. As an outside observer, I understood if he let his child out of her seat, the child would learn that the way to get out of her seat is by yelling and screaming.  The father gave in and let the child out of her seat and stand up.  The flight attendant had other ideas and told the father his child had to be seated.

Let’s look at the behavior and the reward.  The father’s behavior of allowing his child to stand in her seat was immediately squelched, and he was forced to follow the rules.   Can you imagine what happened the second time the father tried to fasten his child in the seat?  The child was more resistant and screamed even louder.  The father made the situation worse by giving into the behavior the first time.  In other words, the father rewarded the behavior of screaming and yelling.

Non-negotiable estimates
I was working with a manager, and I watched him interact with his client (an internal client). The manager estimated it would take 600 hours to complete a project.  His client pushed and challenged him, so the manager reduced the project by 100 hours.  This is a 20% reduction in time.  Then his client pushed a bit more and got the estimate reduced another 50 hours down to 450 hours.  This is a 25% reduction!  Whoa!  What behavior did the manager exhibit and reward?

Estimates need to be non-negotiable.   An estimate should be created using a quantified method.  That means there is some method to creating estimates.  Put some data into a formula and derive the result.  The only thing you should be willing to budge on is the inputs.   There are several inputs with an estimate including size of the project, deadlines, staff, so on and so forth.  Hence, if the estimate is too high, then one of the inputs needs to be changed.
Unfortunately, what traditionally happens is that an estimate is nothing more than a guess.  The estimate has no substance at all; in other words, it is not based upon historical performance or statistical modeling.  Often when working on a contract I ask the question, “How did you come up with your estimate?” More often than not the person actually admits it was a guess.   Another common answer begins, “based upon my vast experience as a software professional.”  In other words, questioning the estimate is the same as questioning their integrity.    It is important for an estimator to be able to quantitatively explain how they derived their estimate.
Unfortunately software development is full of bad behaviors that get rewarded and get repeated.
Read more at Reboot! Rethinking and Restarting Software Development

White Men Can’t Jump and Software Developer’s Can’t Estimate.

There are few things as predictable as software developers can’t estimate.  Nonetheless it software projects follow the same patterns.  Most small projects are underestimated by about 10%, medium size projects by 40% and very large projects by more than 200%.  As project size increases the error rate of the estimate increases with near mathematical precision.

Estimating problems are not to software development.  Gustav Theordor Fechner wrote a book Elemente de Pscyhophysik in 1860.   He coined the term “psychophysics.”   Over the years all the senses have been studied: vision, hearing, touch, taste and smell and the sense of time.   There are three main topics in psychophysical classification scheme: absolute thresholds, discrimination thresholds and scaling.  I am writing about scaling.  It is clear that the untrained are not good at scaling. On the other hand, those individuals that are good at scaling have been trained and they have adopted some sort of strategy to help them measure and then scale.   The point here is that estimating is a skill that can be learned.

The same pattern with estimating is seen over and over again.   A person is pretty good at estimating the height of a 20-foot tree and horrible at estimating the height of a 200-foot building.  The same would be true when they try to estimate the weight of a rock.  They are good at estimating the weight of a ten pound rook and very poor at estimating a 800 pound rock.  So it does not matter if we are estimating the weight of a rock, volume of a liquid, loudness, the height of tree or the size of a software project the error rate increases with size.  As size gets larger the error rate increases.

Musicians learn the specific vocabulary of dynamics.  Trained musicians can hear if one piece of music is being played louder than another piece of music.   As the music gets relatively louder they are able to distinguish loudness because they have been trained to do so.    Musicians are trained in scaling and they have a specific vocabulary for loudness.    They know that piano p means soft while pianissimo pp means very soft.  On the other hand they know that forte f means loud and ff means very loud.    If they are playing their instrument at p and their sheet music or conductor directs to play at ffff they know that means to turn up the volume about six times.   Musicians also know if they are to gradually get louder (crescendo) or gradually get software (decresendo).

You may be thinking that it is lack of experience that prevents people from estimating the height of a tree or loudness.  Wansink studied bartenders with an average experience of over ten years.  He removed all their devices to estimate the volume of liquor  they pour into a glass. When their strategies and measuring devices were removed they were unable to pour the correct amount of liquor into a glass.

The same would be true with musicians.  If suddenly all the symbols and strategies used by conductors to communicate with musicians were removed, then the musicians would have a difficult time playing at the right volume and right tempo. The musician would be constantly asking, “How much louder or softer?”

One of the values of measurement in software is it provides a vocabulary to communicate.  It allows developers to communicate with the core business and explain how much larger. Software developers are not aware of the importance of scaling.  They do not understand scaling is critical to sizing software projects.  The absence of a measurement of scale or an ability to size a software projects prohibits one software project to be compared to other software projects.

WeightWatchers trains dieters how to estimate their food consumption.   It is not just the amount of calories to consider because the grams of fat  and fiber are a important too.  Calories, fat and fiber are combined to determine points.  The point system is a method of scaling food consumption.  The “points” allow one food item to be compared with other food items.

The reason software development can’t estimate is because they don’t measure.   Those few that are successful at estimating software projects have adopted a strategy to size and scale projects.   The best estimators are those that base their size on functionality.

Read more at Reboot! Rethinking and Restarting Software Development.

What is the distribution of effort of a software project

I received an email this morning asking, “What is the effort distribution across a software development life-cycle?”  This is a great question and it is important information for your organization to learn and understand.  I have been tracking this type of data since the 1980’s.

It turns out there is a relationship between how a software organization spends its time and productivity.  The more time it spends in coding and testing the lower the software productivity and quality rates.    Those organizations that spend the most time in requirements and analysis have the highest productivity rates.  The data is conclusive on this point.

In 1980 the best in class software organizations spent about 80 percent of it’s times in coding and testing.  Today the best in class organizations spend about 25% of it’s time in coding and testing.    Today those organizations with the lowest productivity and quality rates spend the bulk of time it’s coding and testing.

While the data does vary depending on the type of industry, the conclusion remains the same regardless of industry.  For example,  the Healthcare industry has the highest productivity and quality rates of any industry.   Those HealthCare IT organizations that spend the most time in requirements and analysis have much higher productivity rates than those HealthCare IT organizations that spend the bulk of its time in coding and testing.

The bottom 25 percentile have a breakdown as follows.

Requirements 15%
Design & Analysis 10%
Coding  35%
Testing  40%

The top 25 percentile have a breakdown as follows.

Requirements 35%
Design & Analysis 40%
Coding 10%
Testing 15%

Read more at Reboot! Rethinking and Restarting Software Development.

Reboot! 4,000 Readers

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

The USA and India had the most readers with about 1,000  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!

Read more at www.RebootRethink.Com

Miracle Worker

One of my favorite movies scenes is in Star Trek III: In Search for Spock. Of course the Enterprise has some mechanical problems. Kirk asks Engineer Scott, “ Scotty, how long will it take to make the repairs.” Scotty replies, “8 weeks Captain, but you don’t have 8 weeks, so I will do it in 2 weeks.” Kirk asks, “Have you always multiplied you repair estimates by a factor of 4.” Scotty eagerly admits, “Of course. How do you think I keep my reputation as a miracle worker?” Scotty overestimates the amount of time it will take to fix the Enterprise and then delivers the project underestimate.

I often thought it would be lucrative to teach people how to become miracle workers.  I could teach people how to inflate their estimates and then deliver early and under budget.  When someone asks, “How did you come up with your estimate?”  Your answer could be something like, “I have 20 years of experience.”  That does not really answer the question, but it  works.  If your client still challenges your estimate then you could respond with something like, “You don’t understand the technology (shake your head and roll your eyes).”  Make sure to  add a few coding words to impress, confuse and intimidate your client.  This should get them to back down.

Read more at www.RebootRethink.Com

What gets missed again, again, again, again…

I often get asked, “What are the common things that software developers miss.”  Hum… requirements.  Let me think about this a bit more, thinking, still thinking, yep it is  requirements.

Over the years I have collected a lot of data and I have had the opportunity to help customers determine why a software project was late or canceled.  The number one reason software projects were late or canceled was due to the fact that the end product requirements were not understood.  The far majority of these projects were greatly under-scoped.  In the end, the projects were a lot bigger than initially thought.

It is not uncommon for a software project to grow 300 precent from requirements to completion.  Yes, I wrote 300 percent.  The problem is that most I.T. organizations have no idea how much their software projects grow because they do not measure anything besides time and cost.  They do not measure functional growth.

So what gets missed, requirements.

Read more at www.RebootRethink.Com

A software application should have no unnecessary functions!

Many years ago I learned a very important idea and this idea has stuck with me and benefited me.  The idea is E.B. White’s seventeenth rule in The Elements of Style:

Omit needless words.
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.

A software application should have no unnecessary functions. Just like writing can be bloated a software application can be bloated too.   The reason software applications have unnecessary functionality is due to the fact the person designing the application did not have a clear understanding of what the person using the software application wanted to do.  Too often it seems like requirements just rain down on the software development team.

The question, “What do you want the software application to do? “ is an incomplete question.   To design a software application well requires the software designer to study how the user does his or her activities.  A software application needs to be designed so it fits naturally into the flow of work or activity.

If the software designer has not studied how a person works and designs the software around the natural work flow, then there is a high probability the software application will be bloated and a lot of unnecessary functionality created.   It would be nice if the rule was expanded and would read as follows.

Omit needless functions
Vigorous writing is concise.  A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines, a machine no unnecessary parts and a software application no unnecessary functions.

For more read the free online book www.RebootRethink.Com