The BALL REPORTS

News As I Like It, Not As You See It:

Myth of the Interchangeable Programmer

Can’t We Just Offshore Him?

And More is not necessarily better...

July 11, 2008

Over the years of watching software projects, I have identified two mathematical formulas that guide much of the industry. These formulas are:
Software Produced = Number of Workers x Hours Worked.
And:
Cost of Software = Number of Workers x Hours Worked x Hourly Cost Per Worker.

I call these the “Software Management Formulas” or SMFs. Understanding these formulas makes much of the absurdity in the industry understandable.

Whether consciously or unconsciously, the SMFs are widely used in the industry. It seems the higher one goes up in the managerial chain, the more likely one is to find the SMFs being employed.

The fact that the SMFs have no relationship to reality has proved to be no obstacle to their widespread adoption. However, understanding the SMFs is the key to understanding the misguided industry clamor over H-1B visas and off-shoring. The value of off-shoring and H-1B visas flows from flawless logic when the SMFs are treated as axiomatic.

Here is real life example of the SMFs at work. A large company originally estimated that it would take about eight developers to complete a project within their schedule of six months. This project was relatively uncomplicated but they did not have programmers available internally. So they used a “bodyshop” to staff the project.

The project was behind schedule almost as soon as it began. The team failed to meet deadlines right from the start. As the project progressed, the gap between schedule and completion increased steadily.

Like many in the industry when faced with a project running behind schedule, this company’s management applied the SMFs to the problem. The SMFs predict that increasing the number of programmers will increase the amount of software produced. So the company went back to the “bodyshop” for more people. The bodyshop naturally was all too happy to add more developers billing by the hour.

With the old deadlines now past, the company revised the project schedule. Unfortunately, even with the larger project team they were unable meet the pushed back deadlines.

As deadlines continued to pass by unmet, the company’s management kept returning to the SMFs and the SMF’s kept telling them to add more people to the project. This process of schedule delay followed by adding more developers continued until the project had over 30 programmers on it.

The company persevered and, eventually, they finished the project. It took about 4 times longer than planned to complete and used about 4 times as many developers as planned. The project was over budget correspondingly.

Now look at the very same project from the programmer viewpoint.

The company placed the entire development team in a large conference room. Each time a telephone rang, it disturbed the entire project team. With eight developers in the room, each one was interrupted eight times as frequently as he would be in a separate office. Each visit from an outsider to discuss project requirements with one person disrupted the entire project team. Whenever two people casually mentioned NFL scores, the whole team became involved in a discussion on football. The physical environment was so chaotic that nothing could get done.

As the management added more developers, the chaos increased. Twice as many programmers meant twice as many telephone calls, with each call disrupting twice as many people. The number of conversations, both business and non-business related, similarly increased. Doing software development under these conditions was simply impossible.

The company kept creating more confusion by adding programmers to the room, and increasing the disruptions geometrically. They stopped adding people to the project only after a Vice President came down to the conference room with a yardstick and confirmed through actual measurement that there was no room to fit any more people.

For reasons completely unrelated to productivity, the project team was eventually moved out of the conference room. With the work environment problem largely solved, the project the project started to move forward, though at a slow pace. Now saddled with over 30 developers, weekly status meetings alone took up an entire workday.

The project should have taken one-third the time it did and could have been done in that time with one-quarter the number of developers.

The problem here is that the SMFs incorporate a number of flawed assumptions. The first of these assumptions is that programmers are fungible. The SMFs assume all programmers will contribute roughly the same amount to a project and that all programmers are interchangeable. If you have a development team of eight, the SMFs assume the individual contributions will look something like this:

The reality is that there are huge variations in skills among programmers. In a typical software development project, the individual developer contributions usually look something like this (note that Arnold is the most productive by far):

The wide productivity variations among programmers have been extensively written about but few organizations take notice. In the real world, one can add 30 programmers to the project and see no positive improvement whatsoever.

 

Your humble Ace Reporter

Bob

Prior | Tell us what you think | Next

Add to Your Social Bookmarks: Del.icio.us Digg Furl Reddit Simpy Spurl Y! MyWeb - StumbleUpon