The Heart of The Matter

I am asked all the time, how can I sell a metrics program in my organization.  The key word here is sell.  Any good salesperson will tell you the key to sales is benefits.

1. There is limited time management has to focus their attention.

  • Management knows when to stay the course or change direction for projects.
  • Control charts can be built with calculated upper and lower control limits.
  • When any indicator is goes beyond a control limit corrective action can be taken.
  • If the project indicators are within control limits, then management can focus on other projects needing their attention.

2. Clients will experience higher levels of satisfaction because communication improves.

  • This will allow clients to have a better sense a project is on time.
  • Clients will be notified of slippage in schedules sooner than later.  They will be able to notify those they have made commitments to.
  • IT staff will be the recipient of better planning and project coordination.
  • Management will make commitments based upon past historical performance not on best guessing.
  • This prevents IT staff from trying to achieve and meet unreasonable deadlines.

3. Metrics allows IT staff members to become empowered.

  • The likelihood of a lot of overtime at the end of a project decreases, so IT staff will not be required to work a lot of overtime.
  • If an IT staff member (or team) is not performing up to standards, then corrective action can be taken
  • Training
  • Reassignment

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.

Tale of Two Captains – Measuring The Internet.

I know all of you are eagerly awaiting some results regarding the “Tale of Two Captains.”   The new Star Trek movie opened yesterday, May 7th.   The number of internet occurrences for Captain Kirk jumped from 1.5 million to 2.3 million in one day.   Clearly the movie is having an impact on the way that Captain Kirk is perceived.    The number of occurrences for Jean Luc Picard remained about the same.

Before the movie a significant number of the internet occurrences considered Captain Kirk arrogant and rude.  It will be interesting to see if the impression of Kirk changes as we learn about his youth.

By the way, an internet occurrence can be a blog, video, news item, website, tweet, or some other event that happens on the internet.

Published in: on May 8, 2009 at 23:12  Leave a Comment  
Tags: ,

How big is the internet?

Since I drink a lot of caffeine I lay awake sometimes thinking about stuff like, “How big is the internet?” I also wonder who is liked more Captain Kirk and Jean-Luc Picard. It turns out these are related questions.

The internet is nothing more than a bunch of blogs, websites, comments, videos, news items, podcasts, music, and now tweets. I am going to call the bunch of things occurrences.  The internet changes day by day, minute by minute, and probably second by second. New things appear like tweets that did not even exist a year ago.

So how many occurrences are there on the internet that mention or discuss Jean-Luc Picard v. Captain Kirk.   The number of occurrences does not equate to good.  It is the difference between famous and infamous or fame and infamy.  In other words popularity does not mean good.

A simple google search yielded 800,000 occurrences of Jean-Luc and 1.5 million occurrences for Captain Kirk.    Not everything said about Captain Kirk is kind.  Say it ain’t so because some people think that Captain Kirk sucks.   On the other hand some people think that Jean-Luc Picard is a sex symbol.  An occurrence can be good or bad.

I found the following occurrence of a question and answer between two people very interesting.  It is about Jean-Luc Picard.

“I am not after a man, I’m a straight male.  I’m simply wondering if shaving my hair off and wandering around in a burgundy jumpsuit using stock phrases such as ‘engage’ and ‘make it so’ would impress the ladies.”

“Jean-Luc Picard is sex on legs and you will be too, when you shave your head and get a burgundy jumpsuit.  You will NEVER EVER want for a first mate again as the ladies will be very willing to be part of your fleet.  Engage and make it so!”

In my quest to measure the internet, I have my first conclusion.  Anything that happens on the internet is an occurrence.  An occurrence be good or bad.  Fame is good and Infamy is bad.  Andy Warhol said, “Everyone will be famous for 15 minutes in the future.”  I think he meant that everyone will be famous or infamous for 15 minutes.  Just ask Miss South Carolina the difference.  With over 35 million Youtube views and over five million other occurences on the internet  she understands the difference.

How big is the internet?  The real question is how do you measure the internet and how do you measure social media.  It turns out these are all the same question.


What is Social Media

Published in: on May 2, 2009 at 21:15  Leave a Comment  
Tags: ,

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

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

Fabulous Adventures in Coding – Benford’s Law

Charley Tichenor and Bobby Davis, just finished an interesting article on Function Points.  They write, “Suppose that software development is a human stimulus and response activity.  The response is customer satisfaction, and the stimulus is the amount of functionality recognized by the user.”  In other words, customers respond positively to more functionality. The authors use Benford’s Law as evidence to support their claim.

Benford’s Law maintains that in a list of numbers (even a list of function point counts) the leading number will be 1 more often than any of other number.   In turns out that function point counts starting with 1 will occur about 30% of the time.   If I examined  my database of function point counts that I have collected for the last 20 years, then I should see more counts starting with a one than any other number.

Charley and Bobby examined  the entire ISBGS’ database and guess what they found.  You don’t have to guess because you can read their paper at

Published in: on April 6, 2009 at 12:19  Comments (2)  
Tags: ,

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.

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