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.

Stone Cold Coder meets Diva Developer!

Cheech and Chong, a 1970’s comic act, portrayed themselves in one of their skits as Siamese twins that were not identical.  They were paternal twins physically connected at the hip.  Of course this was impossible, absurd and a very laughable idea.  Whenever I hear about pair programming I can’t help but think about Cheech and Chong and the absurdity of the idea.    It is like asking two teenagers to share a mobile phone.   It ain’t going to work folks.  It is absurd and laughable.

The idea is that one programmer writes code and the other programmer stands over his or her shoulder and watches for mistakes. When the first programmer gets tired they switch positions.  I think they are suppose to touch hands like professional wrestlers do in a a tag team wrestling match.  How cool would it be to called something like Stone Cold Coder or Diva Developer.  You could go to work dressed in costume.  Instead of programming sessions you could have smack down coding sessions.

You don’t have to implement Agile to try out  the idea of pair programming.  I would suggest  trying pair writing.  Have one person start to type and have another person stand over them and correct them as they go.    This is an awesome idea! I am curious to see how long this process would last.  How about pair cooking?  You have one person cook and another person correct them as they go – nice.  How about pair driving?  You could have one person sit in the backseat and correct the driver.  I think that is called back seat driving.  Sorry pair programming is a joke of an idea and absurd.

——————————————————————————-

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

Reboot! Rethinking and Restarting Software Development.

Agile Methods and Other Fair Tales

If you are having a hard time coming up with a pseudo name for your pair programming team check out the auto Professional Name generator at  wrestles – http://www.wrestlingname.com/

Professional Wrestling –http://www.wwe.com/

Want to read more about “pair programming”

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

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

Measure what is not measurable

It does not matter what is trying to be done, if it can’t be measured, it  can’t be understood , controlled, or predicted.  If it can’t measured it  can’t moved forward.  If the software development process can’t be measured it can’t be understand it.  Measurement has been the basis of all science since the time of Galileo.   The idea of measurement is nothing new; it is only new to the field of software.  If the software development process is not measured it cannot be studied, it cannot be understood, and it is difficult for the organization to move forward. Measurement is one of the most ordinary actions.  We speak its language whenever we exchange goods or information.

Better A Surgeon’s Notes on Performance is a recent book written by Atul Gawande.   The book is an investigation into how medical professionals can progress from good to great.    Many of the lessons outlined in the book apply to everyone including software developers.  Gawande recommends, “Count something. Regardless of what one ultimately does in medicine or outside of medicine – one should be a scientist in this world.”    This applies to software developers too.  To be considered a scientist, something needs to be counted and measured.   It is common for software developers to refer to themselves as a computer scientists or software engineers.  Both of these titles imply utilization of the scientific method, systematic study, and measurement.

Knowing something
The most common and accepted way to know something is through systematic study and utilizing the scientific method.  Another way to know something is through personal experiences.  Through all experiences, each individual constructs a “reality” of the world.  The danger arises when this method is the only method since biases develop or information can be distorted. Often, the events experienced represent a biased sample that in turn can lead to inaccurate conclusions.   Most biased individuals do not see themselves as biased, and often they defend their opinions with a lot of passion. Basically, the scientific method is a set of assumptions and rules about collecting and evaluating data.  The idea is to reduce bias as much as possible, and the proof of the science is the data. “Stripped of fall its glamour, scientific inquiry is nothing more than a way of limiting false conclusions.”

The real conflict in software  is between systematic study and personal opinion.  There are a number of software professionals who rely on personal experience and hold the misconception that systematic study and measurement of the software development process is not possible or not necessary.  Some believe that measuring the software development process is just too complex.

One reason why software professionals do not measure is because they do not have the necessary basic quantitative and qualitative skills.  They do not know how to study a software environment.  Many of them studied computer science where there was an emphasis on learning programming languages instead of learning about the software development process. The emphasis has been on writing code and not on the idea of developing software to solve customer problems.   Since the emphasis has been on programming, it is hard for a programmer to explain how he or she knows what they know.  There is also limited knowledge and experience of what goes on before  code is written and what happens after it has been written.  The reason for this is because there is little interaction with the actual customer or the person who uses the products.  Many developers do not have the desire to know the customers either.

Read more at Reboot! Rethinking and Restarting Software Development

Changes in Lattitudes, Changes in Attitudes

As Jimmy Buffet sings, “Reading departure signs in airports reminds me off all the places I have been.”  I am on my way to California today and whenever I travel it reminds me of all the places and people I have met before.  After 3 million frequent flyer miles, working in every possible industry, and on every contentent there are somethings that are very predicatble.  I can count on software developers saying or maintaining the following positions.

1. Measurement is not possible in the software industry because it is too complex and unpredictable.

Many in the statistics profession, including myself, do not believe in random events.  Some statisticians and mathematicians go mad trying to find patterns.   There is no need to go mad in the domain of software development because many of the patterns are blatantly obvious.   The process only appears to be random because it has not been studied.  It is common for a clinical psychologist to see patterns in an individual’s behavior while the individual is totally blind to his or her own patterns of behavior.   One of the functions of a clinical psychologist is to get people to recognize these patterns and behaviors.   The most common way for psychologists to get people to recognize their patterns is through measurement and keeping a journal.

Many software organizations write journals which are more commonly known as lessons learned documents.  I often review lessons learned documents, and it is painfully obvious the same patterns repeat over and over again. If all the past lessons learned documents are pointing to the same problems, then it is safe to conclude the next lessons learned document is going to point out the same problems. There are only three possible reasons for software organizations to keep repeating the same behaviors: the first is denial and ignoring the glaring fact that the same bad stuff happens in every project, the second is “not my fault syndrome” or nothing can be done about it, the third and final reason it is just too hard to change.

2.  My intuition works better than systematics study.  A wet finger in the air seems to work best for us.

The software developer prefers to use intuition instead of systematic study.  In a method of intuition, what makes logical sense must be true.   I have heard many software developers say, “I know what I know.”   It reminds me of the lyrics from the song “What I am” by The New Bohemians: “I’m not aware of too many things, but I know what I know if you know what I mean.”   If knowledge cannot be communicated via some type of, measurement it is difficult to understand what is meant.  If any process is “too complex” or “random” to be studied using the scientific method by applying measurements, then it is a safe bet that it cannot be studied using intuition either.

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.

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

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.”