Do you suffer from Baumol’s Disease? Even worse, do your top executives suffer from Altitude-Induced Baumol Blindness Syndrome?
Baumol’s Disease … actually, Baumol’s Cost Disease … is one of those brilliant insights economists have just enough of to justify their profession’s existence. And by brilliant, I mean spotting something that’s been in plain sight for centuries, waiting for someone to connect the dots.
William Baumol’s brilliant insight: To play a Mozart string quartet we need the exact same number of musicians, playing for the exact same amount of time, as Mozart did.
The connection: This is why salaries rise, often to unsupportable levels, in circumstances where productivity hasn’t increased at all.
Productivity among string-quartet players hasn’t increased. It isn’t going to increase. If you want to enjoy a live performance, you have to pay four of them. For more productivity you’ll either have to rearrange the piece into a trio or play faster. Either way, “increased productivity” means a very different musical experience.
It’s called Baumol’s Cost Disease because Baumol realized something more — that competition in the labor marketplace isn’t limited to neatly confined distinct positions within which individual candidates compete for work. It’s broader than that.
Every field of endeavor competes with others for talent. If one pays more, it will draw the best talent away from the others.
So if someone with musical talent can make enough more playing rock than classical, that’s what they’ll do … and don’t get distracted by the image I just flashed, of Placido Domingo, wearing Kiss makeup, sticking out his tongue while singing Rock and Roll All Nite.
Which brings us to Altitude-Induced Baumol Blindness Syndrome — confusing the View From 100,000 Feet with how productivity actually works.
When viewed from 100,000 feet, productivity is supposed to increase in all professions, always, and if you can’t make it happen we’ll find someone who can!
Take application development. For awhile, back in the 1990s, purveyors of development tools cared about developer productivity. So-called “fourth-generation” languages and visual development environments helped developers accomplish orders of magnitude more that when writing procedural code.
But at the risk of encouraging a debate that isn’t raging but should be, developer productivity doesn’t seem to be a priority anymore, at least in the mainstream Java/.Net/php environments that dominate these days. (What is? Cross-platform development, maybe.)
So the tools won’t do the job. How about better methodologies? In fact, the move from waterfall to Agile does help, especially with projects where more of the effort goes into the user interface than the business logic.
But most of this productivity increase comes from less business analyst involvement — from developers working directly with business users. We’re cutting out an intermediary, not increasing developer productivity.
Back to musicians for a minute, because in spite of Baumol’s Cost Disease, musician productivity has increased dramatically since Mozart’s day. While live performances still require the same number of musicians for the same amount of time, many more people listen to recordings of Mozart’s string quartets, and listen to them more often, than attend concerts.
The recording sessions take much more time and effort than live performances. Add to that the need for recording engineers and everyone involved in promotion and distribution. But even factoring these in, the ratio of enjoyment received to effort expended has increased enormously.
The same is true when you compare movies and television to stage performances; likewise professional sports. A smaller pool of the best talent now reaches bigger and bigger audiences. Is it any wonder the rock stars in these professions earn so much?
Back to software: Is it any wonder developers working for Microsoft and Oracle earn more than what you can afford to pay? It’s because metaphorically speaking, COTS and SaaS software vendors are parallel to Atlantic and Virgin records. Internal IT is more like a local bar band.
This is where the parallel becomes a bit strained. Compared to a live performance, a recording will have different nuances and less “presence.” Compared to a custom solution, though, commercial software solutions create business constraints that aren’t subtle in the slightest.
Where the parallel isn’t strained in the slightest: Developers are, on the whole, disproportionately smart, with better-than-average analytical skills and the ability to design solutions to difficult problems. Students with the right aptitude will choose programming for a career to the extent developer compensation is competitive with other fields that can use the same skills and abilities.
It is, in the end, an old, old rule of economics: You get what you pay for.
If you’re lucky.
> Students with the right aptitude will choose programming
> for a career to the extent developer compensation is
> competitive with other fields that can use the same
> skills and abilities.
> … old rule of economics: You get what you pay for.
Unfortunately on the other side, besides preparing for the right career that will compensate us justly, it is still a matter of the equally old rule… the job seeker must be in the right place at the right time and looking in the right direction, or be tight with a hiring manager.
“developer productivity doesn’t seem to be a priority anymore, at least in the mainstream Java/.Net/php environments that dominate these days”
I respectfully disagree, Bob. What has changed is that the productivity gains have expanded from IDE-centric approach to platforms / frameworks.
I was doing web development back in the late 90s. I got away from that for about a decade, but am now working on a customer-facing web project for my company. I can tell you, first hand, that there has been a massive increase of productivity for web development projects. Using Wicket, Objectify and Google App Engine, I can single-handedly deploy a scalable AJAXified web app in a fraction of the time it would have take 3 developers to do it 15 years ago. I should note that the productivity gains from two of those three are also tied to IDE improvements – they each have a plugin for my IDE that aids the development and/or deployment process. The productivity gains are definitely there…if you know where to find them.
I’m not to argue with your main point – I’m too far away from the days when I programmed professionally to do so. I do have a quibble, namely, that AJAX wasn’t even a word until the mid-2000s.
Tell me how you measure developer productivity and I’ll tell you if it increased or not.
Bob, Baumol mentioned Beethoven, not Mozart.
The lack of improvement in developer productivity is one of the drivers behind the offshoring of IT. If we can’t improve (or measure improvement in) productivity, then the alternative is to reduce cost by moving development to a low cost site. My experience is that productivity is 30% to 50% lower with offshore development, but that is compensated for by the 70% reduction in hourly expense.
Reminds me of when I asked my dentist if, after investing in several new pieces of dental equipment / technology, productivity was up.
His answer? “It sure is; we’ been able to increase our prices by 5% per year for the last three years!”
I would be interested to know how knowledge/skills fit into this. Seems that the faster you can learn how to do something the more productive you can be at doing it.
Musicians study for years to be able to play classical music well. They learn from many hours practice, education from others, and performances. You could measure their productivity by their ability and speed at which they improve along the way.
The more often those skilled musicians come together to perform as a group, the more productive the group becomes as a whole. But it’s still based on their ability to learn from each other, how to perform best as a group.
It seems to me that improving the learning process accelerates progress toward productivity…with an added bonus of improved quality.