Modeling Programmer Productivity

Continuing where I left off in my previous blog, you may recall that we were discussing the value or otherwise of programming experience in terms of productivity. I had suggested there was an important truth to be learned from the study of productivity models.

"There is a perception in some tech circles that older programmers aren’t able to keep pace with rapidly changing technology, and that they are discriminated against in the software field. But a new study from North Carolina State University indicates that the knowledge and skills of programmers actually improve over time—and that older programmers know as much (or more) than their younger peers when it comes to recent software platforms."

http://www.rdmag.com/news/2013/04/older-wiser-study-shows-software-developers-skills-improve-over-time

This study didn't surprise me. Nor did it surprise many of my programmer friends. Why, then, do so many managers still believe that older programmers are less skilled than their younger co-workers?

The answer lies in fallacious reasoning. Let's see how that works. Pretend we were able to follow the careers of 100 programmer trainees who started together six years ago. Each year, some of them will drop out of programming because they don't like it or can't do it very well.

These dropouts will be high at the beginning, then decline as salaries rise to overcome any residual dislike.

After a year or two, some of the better performers will be offered "promotions" outside of programming. Some will accept. Some will decline, preferring the work they know and do well.

Generally, though, the promotion will be offered principally to those who are the better programmers—whether or not they would be the most qualified to be analysts, managers, database administrators, or what have you.

The following table shows how the allocation of these 100 trainees changes over a six-year period.

The figures are not meant to be exact, but only suggestive of trends.

Now suppose we break down this table into two tables, each starting with 50 of the trainees. First, we have the "least able" 50:

Now consider the most able"50:

In other words, according to this model, after six years, as a result of personnel practices, about 77 percent of the programmers come from the lowest 50 per cent in original ability. The very worst have mostly dropped out early, but not enough to counteract the loss of the better ones.

Most of those better ones have been promoted out to to meet rapidly growing demands for experienced personnel in non-programming jobs. This loss is the result of two fallacious management beliefs:

1. The best programmers will make the best managers, team leaders, etc.

2. There's no point keeping older programmers in the trade because the younger ones are better.

Misled by these two mistaken beliefs, managers keep promoting out their most experienced programmers (except for those few who refuse the promotions).

As an experiment, you might try substituting your own company's personnel policies into this model to create your own tables.

You may find, as many have, that what they are measuring, when they measure "years of experience", is actually combination of "years passed over for promotion" and "years refused to take a promotion.

There's much more to the complex subject of experience, but these simple models are food for thought. Perhaps you'll have them in mind next time you're interviewing a candidate—or even next time you review your personnel policies.

Software Development: Experience vs. Performance

Experience vs. Performance

"Experience is the best teacher."

"Experience is the only teacher."

"Experience keeps a dear school, but fools will learn in no other."

"Experience doesn't necessarily teach anything."

"Experience is the only school in which the test comes before the lesson."

There may be more folk wisdom on the subject of experience than on the subject of love. After all, if we couldn't appeal to experience, how could we old roosters keep control of the henhouse?

When I was young, I was frustrated by lack of "experience" at every turn. No matter how hard I worked, I could gain no more than one year's experience each year. At 19, a year is a lot longer than at year 79.

"Experience" is also proving frustrating to many programming managers, whatever their ages.

"What is the value," I'm often asked, "of one year of programming experience?"

"Does productivity actually increase after the third year of programming experience?" "Don't programmers 'burn out' after five years?"

Quite a few programming managers, if they were asked to plot the productivity value of experience, would produce a graph something like that in Figure 1. They've found that after roughly three years, additional years of experience don't seem to add significantly to a programmer's productivity.

 Figure 1.

Managers who hold this model naturally are unwilling to pay a premium for many years of experience. Usually, they will seek programmers on the job market with one or two years of experience.

One problem with this model is that it may fail to consider problem difficulty. In most shops, the more experienced programmers are given, on the average, more difficult programs to write. If the measures of productivity fail to consider problem difficulty, the more experienced programmers will naturally have their productivity underestimated. In some cases, a more realistic model would be that of Figure 2.

Figure 2.

This slightly less pessimistic curve is supported by the results of a number of studies in the psychology of programming. When programmers of varying experience are asked to perform the same task—coding, finding bugs, developing test data—the average performance versus experience curve frequently looks like that of Figure 2.

Even so, a manager studying Figure 2 may still wish to follow the strategy of hiring programmers with very little experience—in order to take advantage of the steeply rising segment of the curve.

Managers in smaller companies, however, may have more discretion. If they are perceptive, they can profit by noting the difference between each individual programmer and the presumed average.

The same studies of programming support the view that a manager does well by appraising the quality of each candidate's experience. Does the programmer really have "10 years of experience," or is it more accurately characterized as "one year of experience, 10 times?"

If we divide the programmers in each study into two groups—high performance and low performance—we generally find that the experience curves look like Figure 3.

Figure 3.

The curve we see in Figure 1 or Figure 2 is, probably, a mixing of these two curves into a single curve.

Conversely, programmers often tolerate low-paying jobs their first year or two, in order to be in a company that pays well for longevity, rather than for actual output.

Both Figure 1 and Figure 2 represent models of the average programmer in really large companies, employing hundreds or thousands of programmers, personnel policies may force them to follow the averages in hiring and setting wages.

Do these two curves represent anything real, or are they artificial manipulations of data? My own experience with,such studies and on the job tells me that there is an important truth here. In my next blog entry, I'll examine this truth and why so many managers fail to understand it.

Pricing for Non-Profit Organizations

A recent tweet by Harry Tucker raised the question:

Should you work for free?

to which I replied:

No money is okay, as for charity, but they must always pay in some form or they won't value it.

I wrote extensively about pricing in The Secrets of Consulting, much more than I could express in 140 characters. But for those who don't wish to read an entire book, I offer the following essay on the narrow topic of pricing for non-profit organizations:

The First Law of Pricing says:

Pricing has many functions, only one of which is the exchange of money

In addition, The Second Law of Pricing states,

The more they pay you, the more they love you.

The less they pay you, the less they respect you.

If you work with organizations with no possibility of meeting your usual fee scale. You can still help the client respect you by setting the proper price. All you need to remember is The Third Law of Pricing:

The money is usually the smallest part of the price.

There are many costs besides money: the psychological cost of admitting there is a problem; the labor to get approval for your visit; the difficulty of changing schedules; the time and trouble to line up people to see you; plus all the extra work the client must do after you've gone.

By arranging for clients to pay something of value to them, even if it's not paid to you, you have, in effect, raised the price. If they've invested something in bringing you there, they're more likely to listen to you once you arrive. But beware. Even though not much money changes hands you may inadvertently raise the price beyond what the clients are willing to pay.

Knowing that price is more than money, you can increase your compensation in a variety of ways that may not increase the cost to your client. I can sometimes use services such as arranged contacts with prospective clients in the area, computing services, or the use 

of a library.

I often receive free travel to a place I've always wanted to visit. I frequently ask clients to take me sightseeing around their area. Universities are particularly good at this. 

Properly planned, a university visit can be rewarding professionally, far in excess of any fee. Without a plan, you'll just be used, wrung dry of whatever knowledge you have, treated with disrespect or ignored, and then cast aside to find your own way back to the airport.

For me, consulting is a paid education. By arranging visits with brilliant people, I receive the best an organization has to offer, without extra cost to my client—which illustrates The Fourth Law of Pricing:

Pricing is not a zero-sum game.

In short, your gains don't have to be their losses.

* * *

Bio: Gerald Weinberg is author of more than 100 books, including the best-selling The Secrets of Consulting series. He is a principal in the international consulting firm of Weinberg and Weinberg, whose non-profit clients include state and national governments; churches; universities; medical centers; voluntary organizations; and the Library of Congress. The festschrift, The Gift of Time (Fiona Charles, ed.) honors his work for his 75th birthday. His website: http://www.geraldmweinberg.com