Peak code?


“Will human replacement — the production by ourselves of ever better substitutes for ourselves — deliver an economic utopia with smart machines satisfying our every material need? Or will our self-induced redundancy leave us earning too little to purchase the products our smart machines can make?” So ask three Boston University economists, Seth Benzell, Laurence Kotlikoff, and Guillermo LaGarda, and Columbia’s Jeffrey Sachs. In an attempt to answer the question, the researchers turned to — what else? — a computer. They programmed a “bare-bones” model of the economy, featuring high-tech workers (who produce software) and low-tech workers (who produce services), and let the simulation run under different sets of variables.

The results were, as the economists put it in a new paper on the experiment, “disturbing.” The simulation suggests that “technological progress can be immiserating” and that even talented software programmers may face tough times in an ever more automated economy. The reason lies in the durability and reusability of software. Code is not used up; it accumulates. As the cost of deploying software for productive work (ie, the cost of automation) goes down, demand for new code spikes, bringing lots of new programmers into the labor market. The generous compensation provided to the programmers leads at first to higher savings and capital formation, fueling the boom. But “over time,” the model reveals, “as the stock of legacy code grows, the demand for new code, and thus for high-tech workers, falls.”

As a simple illustration, the authors point to the development of a robotic chess player. Once you have a robot that can outperform all human players, the incentive for programming new robotic players drops sharply. This is something we’ve already seen, as the authors point out: “Take Junior – the reigning World Computer Chess Champion. Junior can beat every current and, possibly, every future human on the planet. Consequently, his old code has largely put new chess programmers out of business.” Once any program reaches a superhuman level of productivity in a task, the incentive to invest in further, marginal gains falls.

The authors lay out the resulting economic dynamic:

The increase in [the code retention rate] initially raises the compensation of code-writing high-tech workers. This draws more high-tech workers into code-writing, thereby raising high-tech worker compensation … Things change over time. As more durable code comes on line, the marginal productivity of code falls, making new code writers increasingly redundant. Eventually the demand for code-writing high-tech workers is limited to those needed to cover the depreciation of legacy code, i.e., to retain, maintain, and update legacy code. The remaining high-tech workers find themselves working in the service sector [and pushing down wages in those occupations]. The upshot is that high-tech workers can end up potentially earning far less than in the [model’s] initial steady state.

As usable code stocks swell, the model indicates, we will at some point pass the cycle’s point of peak code — the moment of maximum demand for new code — and the prospects for employment in programming will begin to decline. Code boom will turn to code bust. (The bust will be even deeper, the economists found, if software is distributed as open source and hence made easier to share.) Even though high-tech workers “start out earning far more than low-tech workers,” they “end up earning far less.”

One thing the economists don’t seem to account for is the automation of programming itself, particularly the use of software to perform many of the tasks necessary to maintain, update, and redeploy legacy code. The automation of coding, which would be encouraged as programmers’ wages increase during the boom period, would likely deepen the bust even further.

Computer models of complex systems are always simplifications, of course, but this study serves to raise important and complicated questions about the long-run demand for programmers. It’s become popular to suggest that all kids should be taught to code as part of their education. That way, the theory goes, they’ll be assured of good jobs in an ever more computerized economy. This study calls into question that hopeful assumption. There can be a glut of coders just as there can be a glut of code.

Image of hackathon: Wikipedia.

6 thoughts on “Peak code?

  1. Luke Fernandez

    How well do the economists account for “code rot?” A self contained system might work forever but usually code has to work with other code. And as one set of code evolves, and the other one does not, code rot ensues. Eventually, if the rot isn’t addressed, an application becomes unusable. A good example of this sort of rot happens in Web programming. An app works in one version of a browser. But if the browser evolves (as they have been doing for the past 20 years) and the Web application remains static the application eventually starts to misbehave. In the passage cited above it appears that there’s some consideration of the “depreciation of legacy code.” But that depreciation isn’t incidental which might mean that prognostications about “peak code” may be premature.

  2. Nick Post author

    Fair point. Whether they’ve underestimated ongoing demand for code maintenance, I can’t say. Still, though, the question isn’t whether there will be continuing demand for programming; it’s whether the demand will be strong enough to keep the full supply of coders in good jobs.

  3. Alan Booker

    Nick, your post refers to a “bare-bones model of the economy simulating economic trends.” I would suggest that this model is hardly able to foresee the added complexities/dynamics of a changing cultural scenario, particularrily the technological aspects.

    You also point to the “simple example of a robotic chess player.” I suppose the clue must surely lie in two words, bare bones and simple.

    “disturbing.” Possibly to theorists.
    Peak code? maybe in regards to chess coding.

    I can’t imagine peak code on a grander scale, but there again a computer program might prove me wrong thereby relegating my imaginative powers to lie fallow until we humans wrest back civilization from the one’s and zero’s.

    Warm regards, Alan

  4. Ray Lucchesi

    The essential difference between hardware and software is that software is unconstrained by any physical boundary. This means that software will expand indefinitely and software functionality will continue to increase ad infinitum. This dynamic can be seen in today’s social media services. Such services were never even conceived 20 years ago, barely registered on the world seen 10 years ago, and now most people cannot live without social media.

    Software will continue to expand beyond any physical/logical/virtual boundary that tries to constrain it. Reuse will work at best, only for those areas which exist and are well known already. New software functionality will always be needed and as such, will need to be coded up from scratch.

    The more existential threat to coders as we know it is automating the coding process altogether but then you have human equivalent artificial intelligence which signals a whole other level of problems.


  5. Timothy

    “It’s become popular to suggest that all kids should be taught to code as part of their education. That way, the theory goes, they’ll be assured of good jobs in an ever more computerized economy.”
    It has indeed become very popular and this may be to justify the incredible expense of computer technology in schools, or, it may be that the Programming push is just a faction of the STEM push which is simply an extention of the Math push, or it may be that the only justification for any learning eventually comes down to the idea that it is necessary for future employment. But educators are on the bandwagon. Students at my school work in “HopScotch” on their iPads in grade 4, move up to “Scratch” on a Mac in 5 and 6, and then onto “Processing” in grades 7, 8, and 9. These classes are run with the aim of teaching our students that they “have the ability to learn to code,” and not that they must learn to code. It does teach them a lot about the digital infrastructure and helps to reveal the man behind the green curtain. But, I don’t see a massive need to create programmers. I compare the idea that ‘everybody’ needs to learn code to the idea that everyone needs to learn to be an electrician. I suggest that the previous educational trumpetting (remember Sir Kenneth?) for CREATIVITY and individualized/personalized learning is actually a better way to go. If we could heighten the creativity in our future citizens I expect our society will see a better return on their investment. Programming can be a part of this teaching for creativity, but, I suspect that keeping computer use to a minimum in schools would be even more helpful.

Comments are closed.