Industry Averages Software Productivity

I got an interesting email from a person asking about the variations in software productivity industry averages. I believe the person already knew the answer and was just looking for clarification.

There is no such thing as an industry average cost for software development and there is no such thing as an average industry wide cost for construction either. Since the cost per unit of developing software is so varied, knowing the average cost to develop software is about as useful as knowing the average cost to make something.

1. Productivity varies based upon the size of the project. The larger the project the lower the productivity (higher the unit cost). A project that is 5,000 function points is going to cost more per function point than a 500 function point project. This is true in construction projects too. A sky scrapper is going to cost per square foot (or square meter) to build than a single family dwelling (holding everything else constant). Software development has diseconomies of scale or increasing marginal costs.

2. Software productivity rates vary by type of industry. The software productivity rate for software developed for the health care industry is different than software developed for the banking industry. A medical office is not going to cost the same per square foot (or square meter) as a bank.

3. The way data is gathered will impact software productivity rates. Since I work a lot on mergers and acquisitions, I include everything and everybody not just the IT staff or programming effort. I prefer to use payroll reports and expense payment reports and not just data from time reporting systems. The typical gap between payroll and time reporting systems can be up to 50%. In other words, most software organizations under report its true cost by about 50 percent.

Read more at Reboot! Rethinking and Restarting Software Development

www.RebootRethink.Com

Advertisements
Published in: on December 28, 2009 at 11:29  Leave a Comment  
Tags: , ,

Railroads Industry = Software Industry

I study a lot of things and it turns out the railroad industry is a lot like the software industry.  The software industry is a lot like many other industries.   As an example, the rate of growth for software development is just like the rate of growth for telegraph, telephones, textiles, auto industry and the railroads.  There are some obvious comparisons to the software industry.

  • Large growth (in the USA – 34 miles of track in 1830 to 200,000 miles of track in 1900).
  • Largest employer during its “hay day.”  Nearly 9 percent of the total workforce in 1900.
  • Eventually outsourced work to Asian workers.
  • Cheap labor and automation reduced the demand for rail workers.

Once upon a time, the railroad industry was the world’s largest employer; and, like software jobs in the 1990s’, some of the best jobs were with the railroads.  The railroad industry had similar growth to the software industry.   In the 19th century Europe, the UK and the USA had rapid growth in railroads.   In the USA, there were only 34 miles of railroad track in 1830; and 50 years later, in 1880, there were nearly 100,000 miles of railroad track.  Over the next 20 years, from 1880 to 1900, the number of miles of railroad tracked doubled, reaching 200,000 miles.   In only 70 years the railroad industry went from a dead stop to 200,000 miles of railroad track.

Employment was not limited to just laying track; there was large employment in manufacturing the locomotives, passenger cars, and freight cars.   In the UK, workers built 23,000 locomotives, 73,000 passenger cars, and an amazing 1.4 million freight cars in less than 50 years.   This is an amazing feat when considering the tools and technologies that were available.

The building of the railroads and the railcars that ran on the railroad spawned rapid employment growth in the USA and UK.  The railroad industry employed about nine percent of the total workforce of Chicago.  The rapid growth did not last forever.   Railroad employment peaked in the 1920s, declined during the Great Depression, and rose again during World War II.   Starting in the late 1940s the railroads had to compete against other forms of transportation: cars, buses, trucks and airplanes.   Much of the manual labor was replaced by automation. The railroad companies improved their technology, and they started using diesel locomotives, track-laying machines, and other innovations that reduced demand for labor.

Like the software industry, the railroads suffered from a lack of standardization.  There was no standardized track gauge, the distance between the rails, until the 1880s.  The distance between the tracks depended on who operated the rails. This lack of standardization caused a lot of problems for those individuals that wanted to ship freight or move people from one point to the next.  Parts between freight cars were not standardized either.   This is a similar problem faced by the software industry.   There is little industry standardization for software development.  In the software industry, it is common that software applications developed by the same companies do not communicate and share data.

From 1920 to 1995, those employed by railroads had dropped by nearly 90 percent. In the end, it was a combination of foreigner labor, competition and automation that did the railroad workers in.  In the USA, the railroads were built by cheap foreign labor especially by those coming from Asia.  Software developers are facing stiff competition from India and China (Asian labor).

Quality 911

I was channel surfing and came across the show Nanny 911.  The premise of the show is that there are families who cannot control their children, so they call Nanny 911.  The nanny focuses on the behaviors of the parents rather than the behavior of the children.  A nanny trying to control the behavior of children is analogous to putting your hand in a bucket of water in hopes of displacing water.  Your hand displaces the water, but as soon as your hand is removed, the water goes back to its original position.  The same analogy holds true for the quality department.  It is impossible to enforce quality standards within an organization without holding management accountable.

The nanny teaches parents that children need to have boundaries, and children need to understand there are consequences to their behaviors. Generally, the consequence for the children is timeout.  Since there is no adult time out, a manager can’t put an employee in time out; so, other types of consequences must be adopted.

Too often, quality consultants are focused to helping employees implement a process or fine tune existing processes.    They need to be working and consulting with senior management so management understands they have a role in implementing quality programs.

The bottom line, folks can work, talk, train, cajole, sell, and communicate process until blue in the face; but if management does not enforce the desired process, then the process is not going to happen.  By enforce, I mean there have to be consequences to following the process and for not following the process.  A consequence does include loss of job.  Many successful managers I have worked with do fire people for not following the process, and they also reward those who do follow the process.

Published in: on November 12, 2009 at 18:37  Leave a Comment  
Tags: ,

When the only tool you have is coding…

Abraham Maslow  once quipped,  “If you only have a hammer, you tend to see every problem as a nail.”  If the only tool you have is coding then you tend to see every problem as a programming problem.

Great Software Design Ideas from 1844

The following quote is very applicable  to software development in 2010 even though it was written nearly two centuries ago.

“Great design gives no more than its purpose requires; its artistic resources are the very simplest; its arrangement and relationships are the most natural and comprehensible; it is far removed from all ambition, all splendor, and all overburdening.  It is not rich and does not deceive; but it is certain, virtuously true, and intimate.  It proceeds in a strong, straight line to its goal; and a certain childlike sincerity is evident throughout. “   German Encyclopedia 1844.

http://www.idsa.org/

http://www.bitrebels.com/design/wow-genius-way-to-describe-great-design/

http://joelongstreet.com/

Reboot! Rethinking and Restarting Software Development

Published in: on November 6, 2009 at 15:24  Leave a Comment  
Tags: ,

What we have here is a failure to communicate

Why do bureaucracies emerge in organizations and often overwhelm it?

The real question in my mind is, “What is the root cause for an organizations to have too much bureaucracy?”  It is not like organizations or more correctly individuals within organizations wake up proclaiming we need more bureaucracy.   People do not say, “We need to burden teams with status reporting, forms, procedures until we reach a point in time where everything comes to a screeching halt.”

The idea of small autonomous teams that are unhampered by bureaucracy is not new.   During the 1990’s there was a software methodology called Rapid Application Development (RAD) and today the buzz is Agile. This idea of limiting bureaucracy is not limited to software development.  Going all the way back to the 1940’s there were teams called “Skunkworks” at Lockheed Martin.   The point being idea of self directed teams is not unique to software development and not a new idea.

Some of the clues for burdensome processes come from the word bureaucracy itself.  The term bureaucracy came into use shortly before the French Revolution of 1789, and from there rapidly spread to other countries. The Greek suffix – kratia or kratos – means “power” or “rule”. Does it turn out that bureaucracies are the result of power and rule?

My experience tells me it is not that simple. The root cause for bureaucracies is the result of poor communication.  The cause of bureaucratic burdensome processes is the result of a failure to communicate.   An organization can eliminate burdensome processes, but it does not resolve the problem of communication.  If root causes are not addressed, then problems will never be resolved.

The bottom line is  bureaucracies emerge because of poor communication.  Go though the two links below and look at the recoomendations.  We will begin to notic the opposite is done in software development.  As an example, it is recommended to avoid jargon.  How often is that done in software development.

99 Ways to Improve Communication http://www.getinfrontblogging.com/communication/99-ways-to-improve-your-communication/

Improving Communication Skills http://achievesuccessforlife.com/41/improving-communication-skills/

Sources

http://en.wikipedia.org/wiki/Skunk_Works

http://en.wikipedia.org/wiki/Rapid_application_development

http://en.wikipedia.org/wiki/Bureaucracy

Methodologies and Fad de Jour

According to a recent study Agile is growing in popularity and not long ago the Capability Maturity Model (CMM) was the fad de jour. CMM was based upon sound scientific methods with plenty of data to support its case and Agile is based upon anecdotal evidence. It is not like there are small tweaks of ideas because the difference between CMM and Agile are tremendous.

What is it with software development that causes it to flirt with methodologies as often as weight loss methods? It is like the industry is floundering. It seems that some of the major consulting firms and experts in the field were proponents of CMM not long ago singing the praises of Agile. There seems to be an effort to support and to promote what is popular instead of what is right.

I believe the clue lies in why so many individuals experiment with weightless methods. Consumer Reports declared Weightwatchers the best success weight loss program, but its success rate is low. It is estimated that 95% of those using Weightwatchers eventually return to their old weight. It turns out people (especially Americans) do not have disciplined eating and exercise habits. It is so easy for us Americans to be overweight, to sit in front of the TV, or to spend countless hours surfing the internet. Our portions at restaurants are supersized and there is often an endless supply of snacks at work.
We could excuse the ebb and flow of methodologies on fact the field of software development is in its infancy stages, but I am not sure that is a good idea. In reality, those software companies that are the most disciplined have the highest rates of productivity and quality. This is true of world class athletes and musicians as well. It is especially true of world class golfers. A logical question is what does discipline look like in software development?

What makes software unique from other industries and disciplines is it is so easy to be undisciplined in our methods. It is easy to change a line of code compared to changing a physical structure or a building. The rhetorical question becomes if physical structures of a building could be changed as easily as software can be changed, then would architectural firms adopt the methods of software development?
I have studied hundreds of organizations around the globe as part of a merger or acquisition. It turns out those that are the most disciplined with repeatable processes are the most successful. It is critical to note that being disciplined does not guarantee success. It seems the missing ingredient is customer knowledge. The formula becomes those organizations with discipline and those that study the customer are the ones with world class performance levels.

Yet the unanswered question remains.  What are the reason so many software development organizations flirt with so many methodologies?

http://www.googobits.com/articles/625-the-skinny-on-fad-diets-what-really-works-what-definitively-doesnt.html

http://www.RebootRethink.Com

http://www.internetnews.com/dev-news/article.php/3841571

http://blog.nayima.be/category/agile/

http://www.sei.cmu.edu/cmmi/

Movie Making and Software Development

The role of the project manager and software manger are often missed understood. Movie making and software development are very similar types of creation.  A brief examination of movie making and comparing the roles of director and producer will give some insight on the differences of the project manager and software manager.

The director of a movie is similar to an IT Manager.  They are responsible for day to day activities.  It is common for many directors to not have any acting experience.  For example Steven Spielberg, winner of numerous academy awards, has never acted.  On the other hand Clint Eastwood was an acclaimed actor prior to becoming an award winning director.  The directors, like an IT manager, is responsible for the management of staff.

There are many technical aspects the film producer need to coordinate.  Besides the actors and actresses it is important to have the right film crew, lighting, sound, editors, animators, so on and so forth.  The producer may or may not have intimate knowledge of any of the technical roles.  The software project manager is responsible for getting the right business analysts, coders, testers, software engineers for a project.

Producers like the software project manager are responsible for the planning and the execution of the budget and insure the project comes in on budget and schedule.  An executive producer may coordinate the activities of several producers similar to the role of a project management office.

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

Who does what? http://www.directortom.com/director-tom/2007/8/17/executive-producer-producer-director-who-does-what.html


A production manager – a rose by any other  name

http://filmindustrybloggers.com/blog/2009/10/13/the-production-manager-a-rose-by-any-other-name%E2%80%A6/

Technical Support Cheat Sheet – Cartoon

A friend of mine sent me this cartoon that outlines the steps necessary to solve most technical problem. The great thing about this cartoon is that helps people learn the steps necessary to solve problems instead of providing an answer.

Technical Support Cheat Sheet

Technical Support Cheat Sheet

Read  more at Reboot! Rethinking and Restarting Software Development

Published in: on August 24, 2009 at 11:20  Comments (2)  
Tags: , ,

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