Returning to my theme of numerical and economic analysis of software development, I’d like to address that old chestnut:
Shouldn’t every developer work on the software where they are most productive?
We can model this question using a bit of economic theory called Comparative advantage – which is also the economics that justifies free trade. However, while this model will give us an answer it also raises a number of questions which are outside the model. In this case the model gives us a structure for examining the issues rather than providing an answer.
By the way, this discussion is going to span two blog posts, or perhaps three.
Lets set up the model with a simple case. As before there are some assumptions needed, its when we examine these assumptions that things get really interesting.
Imagine a small trading desk. The desk invests in corporate bonds and equities. Jenny has been working for the desk for some years and has written two applications for trading imaginatively called Equities and Bonds. She wrote Equities after Bonds and prefers Equities and is more productive on Equities.
Measured in features Jenny can produce 5 new Equities features or 4 new Bonds features in one week. (We’ll assume that all features are the same size for now.)
The company hires a new developer, Joe. He is new to the code bases he can only produce 2 Equities features or 3 Bonds features a week. Thus Jenny is the most productive developer on both apps.
| Features per week | Equities | Bonds |
| Jenny | 5 | 4 |
| Joe | 2 | 3 |
Now comparative advantage theory tells us not to look at the total output of either party but at the relative output. In other words:
- For Jenny every bond feature costs 1.2 equities features. Equally Jenny can produce one equities feature at a the cost of 0.8 (4/5ths) bonds features.
- For Joe every bond feature costs 0.66 (2/3rds) equities features. Or, to put it the other way round, Joe’s equities features cost 1.5 bond features.
Looked at this way, relatively, Jenny is a better (more productive) Equities developers and Joe is the most productive Bonds developer.
Think about that.
During one week Jenny can produce more Bonds features than Joe but when measured in terms of the alternative Joe is the more productive Bonds developer. This is the important point. You might say “look at everyones individual strengthens.” Relatively Joe is better at Bonds.
Together Jenny and Joe could produce 7 features for either product. If Jenny works where she is stronger, Equities, and Joe works where he is strongest, Bonds, then together they will produce 8 features. If they both worked on their weaker product then they will only produce 6 features combined but four of those six would be Bonds features.
So, it seems the case solved: Everyone should specialise and work on the product where the individual is relatively strongest. Although this is not necessarily the same as “who is the best developer” for a product.
But… things are more complex. Now we have the model we can start changing the assumptions and see what happens.
First off, we could relaxed the assumption about all features being a different size. However this doesn’t make any real difference. It doesn’t matter how big a feature is, Jenny is always 20% more productive on Equities than Bonds and similarly Joe is 50% more productive on Bonds than Equities. Using different size features complicates the model without creating new insights.
Varying the size of features doesn’t change the integrity of the model but it does make a difference if we start to look at throughput and consider time.
So lets relax the time assumption. What happens if Joe is in the middle of a Bonds feature and another feature gets flagged up as urgent. Should Joe drop what he is doing and pick up the urgent Bond feature?
The model doesn’t answer this question. The model is only measuring output. If we are attempting to maximise output then changing work part way through the week only makes sense if the both pieces of work – the part done original and the urgent interrupt – can still be completed by the end of the week.
So one needs to ask: is the feature urgent enough to justify Joe halting his current work and doing the new feature? Then perhaps returning to his current work?
Possibly but in making one feature arrive faster another would be delayed. Statistically there is little difference because the differences cancel each other out. Which itself demonstrates how managing by numbers can be misleading.
And what is Joe couldn’t finish both pieces by the end of the week? Would it make sense to reduce overall efficiency to expedite some work?
What if Jenny becomes available, should she work on Bonds? Even though she is relatively less productive at Bonds and would thus delay even more Equities features?
These questions can be answered in many different ways but answering them depends on what you are trying to maximise. And lets also note that in real life the data is unlikely to be so clear cut
On average Joe takes two and a half days to complete an Equities feature while Jenny completes one Equities feature a day. On average Jenny can complete her current feature and a second one before Joe could. But it doesn’t take much to invalidate that answer, in particular if feature sizes vary things change.
What if Jenny is working on an over-sized feature? – well call it urgent #1. Suppose urgent #1 is twice as big as urgent #2 and she has just started #1. Jenny will take three days to finish both features. If goes starts urgent #2 he will have it finished in 2.5 days, during that time Jenny will have urgent #1 finished. Looked at this way it makes sense for Joe to work on the highest priority even if it takes him longer.
And what happens if Equities has three, or more, urgent features? Even with Joe working more slowly than Jenny all the urgent features will be delivered sooner if Joe works on Equities too. Again, total productivity would be impacted but what is more important: total productivity or rapid delivery?
If efficiency is your objective then all is well, simply understand the relative efficiency of individuals and do the maths. (Except of course, understanding the efficiency of any individual isn’t that straight forward.) Adding time dependent features complicates things, the comparative advantage model helps show the cost of urgency although it cannot answer the question.
It is entirely possible, even likely, that efficiency is not the only concern, it may not even be the primary concern. Rather the timeliness of feature delivery may be more important.
Specifically, I have assumed that all features are about the same effort but I’ve assumed they are also the same value. Efficiency has been measured as quantity of units produced is a poor measurement compared with efficiency in value delivered. I’ll turn my attention to value in the next blog.
But before I leave this post, one more assumption to surface.
In this model Joe and Jenny are completely independent. There work does not impact the other and they share no resources. What if they did?
What if both Joe and Jenny handed their completed work to the same Tester? Or they both needed use of s single test environment? Or their work needed to be bundled into a common release?
In such cases the shared resource – the tester, the environment, the release schedule – would become the constraint on productivity. This is getting towards Theory of Constraints space.
For Joe and Jenny to work at their most productive not only would that bottleneck need enough capacity to service them both it would actually need more capacity to cope with the variation and peak load (when Jenny and Joe delivered at the same time.)
Providing that extra capacity at the bottleneck would allow Joe and Jenny to work at their maximum throughput but would introduce waste because the extra capacity would sometimes be idle. To tackle that question one needs a far more complex theory: Queuing Theory – which I’ve discussed in previous posts, Utilisation and non-core team members and Kanban: efficient or predictable, you decide.
Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.
