Can economic theory show us a more productive way to build software?
In the software industry we talk a lot about different roles, job titles, and responsibilities on a software development team. From UI designers, to Full-stack developers, to DevOps specialists — the list of jobs, titles, and responsibilities is almost endless. There is frequent debate about whether designers should learn to code and whether developers should learn to design, and even debates on whether to have full-stack developers vs. more specialized roles.
These are valuable discussions and debates. We should continue them as our industry evolves and matures. The answers will evolve as well.
In these discussions, we should consider whether two specific economic principles, the division of labor and comparative advantage, could suggest more productive ways to organize our teams and the work to be done. These principles are related but each brings something different to the discussion.
Let’s take a look the two concepts starting with the one most people are probably familiar with and unlikely to have much disagreement about: The division of labor.
Division of Labor
Adam Smith famously recognized the benefits from the division labor over 200 years ago:
According to Adam Smith, these (benefits) include increased dexterity from learning, innovations in tool design and use as the steps are defined more clearly, and savings in wasted motion changing from one task to another.
The reason is that division of labor produces a cost advantage where none existed before — an advantage based simply on specialization. Division of Labor
From its name, most people intuitively understand what we’re talking about here. The idea is that there is an economic and productive advantage when we split work into separate tasks, activities or jobs that different people can specialize in. The work becomes more productive and efficient because when someone specializes in a particular job, the more skilled, and the more efficient they can become at it. Multiply this across all jobs and the gains in efficiency overcome the costs (or what economists call “transaction costs”) of coordinating these specialists and handing work from one step to another.
Of course there are limits to how much we can divide labor before the transaction costs exceed the gains in efficiency from specialization. Every industry, as it evolves and matures, is adjusting their thinking about the best mix of specialization and generalization. As certain jobs become more complex, there are potential gains from more division of labor and specialization.
Even in the software industry, where we have a fair number of generalists, the Full-stack developer who does everything including UI design, UI coding, testing, API development, database design, DevOps and so on — the division of labor isn’t particularly controversial. We still have people who specialize in each of these areas and even focus on finer-grained specializations (e.g., the developer who doesn’t design but only codes the _UI_…no back-end development at all.)
But we have a small problem in our industry. We have a lot of really smart people working in it. Many of these people have taught themselves many if not all of the aspects and skills of their jobs. I mean there are lots of really smart folks who are capable of doing various jobs very well. They’re very capable of designing, coding, setting up servers, designing the database and so on…very well. They’re that smart. When you’re that smart and skilled at many things, it can be hard to see how the division of labor and specialization will increase efficiency very much. Fair enough. But economic theory has an answer for that too. Let’s look at the concept of comparative advantage.
When asked by mathematician Stanislaw Ulam whether he could name an idea in economics that was both universally true and not obvious, economist Paul Samuelson’s example was the principle of comparative advantage.
Donald J. Boudreaux, Comparative Advantage
The concept of comparative advantage is definitely neither obvious nor intuitive. But what it brings might actually be more profound and beneficial than our friend the division of labor.
With comparative advantage you’re not concerned with whether person A is better than person B at a given job — or vice-versa — but how much better they are. Let’s dig in.
We’re all good at something. Some are good at many things. But when looking at comparative advantage we want to figure out what you’re “most best” at. Using an example from this article let’s consider two roommates deciding who should cook and who should clean:
But what if your roommate is a veritable Martha Stewart, able to cook and clean faster and better than you? How can you earn your keep toward this joint dinner? The answer is to look not at her absolute advantage, but at your opportunity costs. If her ability to cook is much greater than yours but her ability to clean is only a little better than yours, then you will both be better off if she cooks while you clean. That is, if you are the less expensive cleaner, you should clean. Even though she has an absolute advantage at everything, you still each have different comparative advantages.
What’s going on here is that because person A — who is better than person B at both cooking and cleaning — is “more better” at cooking, both will benefit and get more done if Person A focuses on cooking, while person B focuses on cleaning. Let’s be perfectly clear here: Person A is better at both jobs than person B but they both benefit the most when each focuses on one job. Don’t believe me? Let’s look at this mathematically.
We’ll use the example from this article.
First let’s assume two people, Bob and Ann, produce only two things, bananas and fish. If they specialize in either, here’s how much they would produce:
In other words Bob can either produce 50 bananas _or_ 50 fish, and Ann can either produce 100 bananas _or_ 200 fish. Notice that Ann can produce more of either than Bob.
But, they both want fish and bananas, so if they split their respective time on these jobs, here’s what they can produce and consume:
Here’s the problem: Bob would like to eat the 25 bananas but also eat more fish and Ann would like to eat the 50 bananas and also eat more fish. How can they achieve this? The key is for Ann, who is more productive in both, to focus more on the one she is “more better” at. If they do this, here is what each might produce:
Notice Bob is not producing any fish, but he desires some (and has more bananas than he wants or needs). Ann has fewer bananas than she wants and more fish than she needs. Now it’s time for trade. Here’s what happens when they design to trade their respective surpluses:
See that there is actually more produced in the scenario where Bob focused on bananas and Ann focused (more) on fish. The same total amount of bananas is produced, but more fish and both have their wants and needs satisfied.
Also notice that neither has directly increased their productivity (which could happened at some point as we learned from the division of labour). This is the result of merely focusing on what job each is relatively best at even though one is actually absolutely better at both jobs.
I’m not suggesting we can (or should) always measure our work in such a mathematically precise way. That’s not the point. That is just a way to explain and illustrate the concept. The fundamental point is that there are overall productivity gains to be had just by each of us choosing to specialize in the thing we are most good at and working (trading) with others to do the things which we still might actually be better at. Even without direct improvements in efficiency from specialization. If that happens, it’s just another bonus.
So what does all of this economic mumbo jumbo mean for the software industry? It’s fairly straightforward: If we want to maximize the overall productivity of our project, team or company, we should look carefully at our people and see if we can determine where each person has the greatest skill gap and allow them to focus and specialize in that job. Ann, the designer, might be able to design and code better than Bob the programmer. But, if her advantage over Bob at designing is larger than her advantage over him at programming, it might be best for her to focus on designing and have Bob focus on development.
The focus of this article is on gains in productivity. There are plenty of reasons you might chose to not specialize: personal preference, cross training, career development, etc. But sometimes it’s useful to look at what economics can teach us about how we go about our work and how we can be better contributors.