Studies of individuals have consistently shown variations of 20:1 or more in schedule, cost, and error performance among professional programmers, so it makes sense that this is the level of variation we see in Pattern 1.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 2

I’ve been thinking about this concept a lot again recently. This sort of figure crops up again and again in all sorts of places. It’s a reasonably well known concept, and reasonably self-evident to anyone who’s worked around enough programmers. So why is virtually no-one interested in the concept?

Yes, you get people writing about “software productivity”, but these tend to fall into two main camps. The first, who usually have something to sell, write about the newest, greatest Silver Bullet that will increase everyone‘s productivity by an order of magnitude.

The second, the more thoughtful consultant types, work hard with companies to smooth all their processes, and slowly move them up the CMM scale, or, in Weinberg’s case, his Six Degrees of Congruence.

But again, this is about raising the company’s level, as the totality of everyone. Although it’s rarely explicit, the implicit assumption is that it’s bad to rely on these “super-programmers”, and you need repeatable processes that work even if you lose your star performer(s). As Dijkstra put it:

Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its workforce

Both of these approaches miss the point, in almost exactly the same way. They don’t concentrate on why some programmers are 20 times more productive than others, or whether it’s possible to create more of these star programmers.

Perhaps it’s just that people just don’t know how to cope with this entire concept. Bob Morris, in his keynote at the Emerging Technology conference earlier this year, talked about how in the last 100 years, $1000 worth of computational power has increased by 14 orders of magnitude – an unprecedented scale that people find difficult to conceptualise. But, in most fields of human endeavour, people can’t even conceptualise one order of magnitude. The world record time for running a mile is around 3 minutes 43 seconds. Even an average runner can run a mile in less than twice that length of time. This plays out again and again: the best is maybe only twice as good as the average. The difference between professionals is much less. In Formula 1, where cars go at speeds in excess of 200 miles per hour, the significant difference in lap speeds is often measured in hundredths of a second. (At those speeds we do get our factor of 20 over the human running that mile, but with huge costs and a lot of ‘artificial’ aids that can raise most people to the same levels)

In the workplace it’s not very different. You won’t find a call centre with an two employees, one of whom handles twenty times more calls than another (at the same, or even better, level of quality). Or two secretaries, one of whom can type twenty times more letters than the other.

We’re not used to dealing with these levels of differences between people, so we don’t know to deal with it when it happens.

And, with programmers, it’s hard to actually see it happening – not at the detail level. We know that Fred gets much more done than Barney, and can do most jobs in a fraction of the time, but we can never quite see how. When we look closely, they both seem to do the same thing. There’s no obvious flaw in Barney’s approach, or obvious methodological differences that could be applied. It just seems to happen, so we write it off as just an anomaly.

Managers in “lower” organisations on most of the “quality scales” rely on the fact that they can give the work to Fred, and have it done quickly, whilst always having that nagging fear of Fred moving somewhere else. Manager in slightly more “advanced” organisations know that they can’t rely on Fred, so they work out all their schedules and budgets based on Barney instead. Neither attempts to make Barney as productive as Fred. They may wish he was, but neither think it’s possible.

Why?

Did you know that if you were 8’6″ tall, you could get a job as a starting center with a team in the NBA and earn $3,000,000 a year? Now that you now that, why aren’t you starting on a growth program? It’s a silly question, because you don’t know how to grow several feet taller.

Did you know that be reducing the faults in your software to fewer than one in a million lines of code, you could increase your market by $3,000,000 a year? Now that you know that, why aren’t you starting on a quality program. It’s a silly question, because you don’t know how to reduce software faults to fewer than one in a million lines of code.

I frequently talk to managers who are seem obsessed with cutting the cost of software, or reducing development time, but I seldom find a manager obsessed with improving quality. When I suggest measuring the value of quality, they often respond as if I told them to measure the value of growing to 8’6″. Why bother measuring the value of something that you don’t have the slightest idea how to achieve. And why try to achieve something whose value you don’t appreciate?

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 1

For thirteen years, I took IBM seriously, especially its THINK motto. IBM was right. Thinking was essential. But after a while, I noticed that IBM and its customers often honored thinking, but didn’t practice it. As far as I could tell, little THINK signs on each desk never helped us get software out the door. Yet IBM managers never seemed to do much else to help the process. Later, after I left IBM for an independent consulting career, I learned that IBM’s managers were no different from the rest. All over the world, software managers gave lip service to thinking, but didn’t do much about it. For one thing, they never understood the reasons that people didn’t think when they ought to. Of course, I didn’t understand either.

In school everyone told me how smart I was. True, I did outstanding work on all sorts of tests, but I never seemed to be able to think effectively about my own life. I was a miserable kid, and I thought that thinking machines might help me solve my problems.

Well, thinking machines didn’t solve my problems; they made them worse. When I tried to build software, the computer unfailingly accentuated all my mistakes. When I didn’t think right about a program the program bombed. The computer, I learned, was a mirror of my intelligence, and I wasnt’t too impressed by my reflection.

Later, when I wrote larger programs in concert with other people, I learned that the computer was not just a mirror, but a magnifying mirror. Any time we didn’t think straight about our software project, we made a colossal monster. I began to learn that if we were ever to make good use of thinking machines, we would have to start by improving our own thinking.

— Jerry Weinberg, Quality Software Management Vol 1, Preface.

This is the same problem people have when writing prose. They think it’s like speaking, where if you say something wrong you can correct it with the next thing out of your mouth – well, not correct it really, but improve it, that is, when you didn’t say it perfectly in the first place and then you have a new idea – it’s sort of like oil painting rather than water colors, if that helps you understand what I mean, but in case you don’t know about painting, you see, with oil colors, you can scrape the paint off if you make a mistake and paint over it (actually, you can’t scrape it completely off, because a little of the residue will impregnate the canvas, but almost all will come off and you can paint over it – that is, unless you’re painting certain light colors over dark colors that might bleed through, well, not bleed through exactly, but can be seen through the light color and maybe influence its impression a bit – not for all viewers, but those with … The delete key is the writer’s most important tool; same for software writers

— Jerry Weinberg, Roundtable on Technical Leadership

Oooh. A new David Maister book. (I discovered this through a review in the Journal of Business Strategy. I though I’d told Amazon to notify me of any new books by Maister, but obviously not.)

Managers often fall into the trap of looking for problems to be fixed rather than seekign successes that can be multiplied. This results in everyone being risk averse and cautious. It does little to encourage the vital task of regularly finding new ways to do the job better.

Also in the Mar/Apr issue of Operations Research is an article on modelling demand for services when upgrades are available. Many of the service industries have policies in place to cope with excess demand – upgrades to a higher model of rental car, or to business class seats on an airplane, for instance. Although these policies are well documented in most of the organisations, they’re apparently poorly monitored for purposes other than internal policing. The authors of this paper posit that “significant benefits can be gained if the possibility of service substitution is accounted for at the time of capacity planning, rather than only at the time of service delivery.”

The Mar/Apr issue of Operations Research has an interesting article on credit scoring models. Traditionally credit scoring has been about minimising the risk of making loans to customers likely to default on the loan. But over the last few years people have started to realise that this probably isn’t enough. In fact, even a customer who has a high likelihoold of default could actually be profitable as long as the default comes far enough in the future for the interest payments made before that point to exceed the losses caused by the default.

The real issue for most lenders now is the risk of the customer paying off their loan too early for the lender to make any money. This often happens with the borrower switching to a competitor – a practice that has become particularly rife in the Credit Card industry – more and more customers are moving their balance to a new card with a super-low introductory rate (often 0%), and then moving to a competitor when the introduction period runs out. Similar things are also happening more and more in the mortage industry, and increasingly so in “normal” personal loans.

Traditional tables of “likelihood of default” provide average figures based on a variety of characteristics of the borrower tabulated against the purpose of the loan, that can be used to decide how risky the loan would be. Unsurprisingly, the likelihood of switching in each of these cases is very different from the likelihood of defaulting.

I’m curious now how long it’s going to be before information like this starts to be taken into account on people’s credit reports, or asked for on applications. Most credit card applications ask how many other credit cards you have, but I don’t think I’ve seen any yet that ask how many you have had…

This is quite an old book now by Jerry Weinberg (1982), and it has dated quite significantly – more so than Mythical Man Month which is a few years older.

Most of the programmers in this world were writing COBOL, PL/1 or raw assembler. And so many of the examples he gives don’t really translate well. (Although the extended example in “Say what you mean and mean what you say” could easily be translated in Java and show up in an Extreme Programming book). And cost analyses on the best way to teach computer programming when machine time was so expensive seem to come from an eerily distant past now.

But once we get into the middle of the book, much of the material tends more towards the “psychology” of programmers, which hasn’t really dated. And there are a few nice ideas that still haven’t really caught on. I particularly liked his idea that computer languages should be taught in pairs, with all the examples and exercises given in both languages. With natural languages the most difficult to learn is always the second. A third, fourth or even tenth language is much easier. The same seems to be true of computer languages also. So, teach people to be bilingual from the outset. Let them see how different languages would approach the same problem.

Although the book is on the surface aimed at programming managers, most of the articles really seem to be aimed at programmers who need to learn how to deal with programming managers. And, if anything, the problems he points out with the gap between programmers and managers seem to have widened rather than closed. As Weinberg writes: Code is to programming managers what dirty dishes are to a headwaiter. Once you have graduated from the garbage heap, you never touch the garbage again – even in jest.

The “Cost of Inadequate Software Testing Infrastructure” paper I linked to a few days ago had a chart that showed that the percentage of project time given to actually writing code had dropped significantly in the last few decades as more and more time went in to specifications, analysis, design etc. I doubt most managers read any more of the actual code that gets produced these days.

This is a book that treats coding seriously. Weinberg argues that contrary to popular opinion, now as much as then, coding is a valid profession, and a skill that takes years to master, not days or weeks. This idea has obviously had a resurgence recently with books such as Pete Breen’s Software Craftmanship, but it’s interesting to go back twenty years and see the articles that were being written then.

Probably not worth going out of your way to find, but worth a skim through if you find a copy.

A wonderful study of a government project that was prototyped in a variety of languages (Ada, Haskell, Lisp, C++, Awk etc.)

Unlike several other such studies each was written by a senior programmer in that language – not all by the same developer. Although the results are impressive in and of themselves (Rapide took 54 hours to develop, Lisp, 3 hours; C++ took 1105 LOC, Haskell 85 lines), it’s more interesting the response to the Haskell solution, which was written, Literate Programming style, as executable LaTeX. Because the code was so small, but the documentation so large (85% of the solution was documentation), the reviewers assumed that this was not a complete, tested, executable program, but just a specification with some top level design!

[Thanks to Malcolm Wallace for the link.]

Most books I’ve read on User Interface Design support their theoretical approach with copious examples. This one takes the opposite approach. Most of the book is taken up with describing the evolution of an instant messaging client, and how its UI developed. This is made interesting because the software was developed simultaneously for Windows and for a PDA. However, I’d never heard of the product (Hubbub) before reading this book. This isn’t necessarily a problem, as there’s still a lot of useful ideas here (and as far as I’m concerned, the more books that reinforce the concept that most software is still really badly designed, the better), but I can’t help thinking that the book would have been more useful, or at least more interesting, if it was the story of the development of a product I actually used.