I love a cold beer. Not just because it’s refreshing and makes me worry less about the world’s problems, but also because of beer’s fungibility. Let me explain; I can go down to the store and buy a beer and it’s pretty much the same as any other beer I might purchase elsewhere. Sure, there are different standards of beer and I’m going to pay a few dollars more for my favourite Little Creatures than I am for VB but in essence I’m still getting hops and yeast with some water.
The point about fungibility is that beer is the same basic product no matter which one it is you’re drinking. In short, beer is a commodity.
Coder commoditisation
Commoditisation occurs once people start believing that a good, in the case of this post a coder, can be acquired without qualitative differentiation. In simple terms it’s the mindset that CoderA == CoderB == CoderC. There are obviously cases where this is true but the commoditisation I’m referring to is the broad-brush assumption that software development is a consistently repeatable process with the same end result from the same amount of effort regardless of the person at the keyboard.
You can spot coder commoditisation in action when you see comments like this:
Don’t worry, we’ll just get unknown CoderB to step in while CoderA is away.
Or the classic financial argument:
Hey, we could get unknown CoderB for 25% less than what CoderA costs!
These are commodity based statements in that they assume CoderA can be mutually substituted by CoderB whilst achieving the same results in the absence of quantifiable knowledge of their skill level.
Building software is simple - if you know where to look
I don’t actually believe that software development is a complex process. Very tricky problems can be solved by smart coders with such ease and grace that the practitioner barely raises a sweat. They know the shortcuts, the pitfalls, the well trodden paths to coding success and when they tie it all together the process becomes simple, elegant and most likely successful.
The key observation here though is that this person is clear about what they’re setting out to do. They have the pieces of the puzzle and a mental image of what it should look like once they put it all together. What’s more, they’ve successfully performed this process many times before. These are the people who take something complex and make it look easy.
Compare this to the coder who simply cannot put the pieces together. Either that or the effort it takes them is substantially different. There are numerous potential causes of this; they may be poor at problem solving, unable to ask the rights questions to understand the requirements, have a poor grasp of the technology or possibly they’re just lazy!
Oils Ain’t oils
Just like engine lubricants, when it comes to coders Oils Ain’t Oils. Castrol would have you believe that not all oils are created equal and the same is true of the coder. When it comes to coding we’re talking about a process which has a huge number of variables in terms of how software is built. The process is then performed by people from extremely diverse backgrounds in terms of culture, education and experience.
One thing that separates software development from many other industries is that people become coders by following very diverse paths. If you want to become a doctor, you go to medical school. If you want to become a lawyer, you go to law school. If you want to become a coder, you start writing software in your basement when you’re 15. Or you start doing it as the “shadow IT” guy alongside the reason you’re actually at your place of work. Or you possibly go to university but often it’s to study engineering. It’s because of this people diversity that we simply cannot expect consistency in either effort or output from the process of writing software.
Quite frankly, some people are just very bad coders. Certainly underperformance is not unique to the software world, you could be a bad chef or a bad cleaner but the difference is that poor quality work is immediately apparent whereas the handiwork of a bad coder often does not become obvious until long after the work is done. Oftentimes the coder has the advantage of relatively anonymous work. I know if my steak is overcooked and I know if the kitchen in the office hasn’t been cleaned but quite frankly I have no idea what happens to my internet banking credentials after I hit the submit button. Unlike the chef or the cleaner, the coder’s work is not usually unmasked as sub-standard unless a peer of equal or greater knowledge is exposed directly to it.
Offshoring
One area ripe for commoditisation is outsourcing to low cost markets. A key rationale for sending work offshore is that resource costs are lower. Why pay $100/h in the Western World when you can send the work to an emerging market at a fraction of the cost? Once again though, this assumes the people can be commoditised based purely on an hourly rate. What this rationale often does not consider is the quality of the resource.
I’m not saying resources in your typical offshoring locations are necessarily inferior. The commoditisation argument would be the same if the tables were turned; without sufficient due diligence to quantify the capabilities of the resources you’re still making the assumption that writing code is a mutually exchangeable activity regardless of the individual.
Obviously the “win-win” situation is to leverage high quality, low cost resources but this only happens when commoditisation is not the sole focus and an understanding the coder’s competence is gained. Only then can the decision be made holistically based on both competence and cost but without both pieces of information only part of the picture is clear.
The Mythical Man Month
So why not worry less about putting high quality coders on a project and just focus on cost? Why not grab twice as many people for possibly a third of the price from a low cost market and not even bother with all the rigmarole of attempting to understand their capabilities? The answer is described in Fred Brooks’ The Mythical Man Month through Brooke’s Law:
Adding manpower to a late software project makes it later
Brooks describes his point through this now popularised saying:
Nine women can't make a baby in one month
In The Mythical Man Month, the author talks about how an increasing number of people in a project increases not only the total amount of project familiarisation which is required (which is linear as numbers increase), but more importantly how much extra communication is required which increases exponentially with greater numbers. Joel Spolsky illustrated this recently in his column about A Little Less Conversation where he demonstrates how connections increase in relation to people. More connections mean exponentially more communication which means less output.
| People | Connections |
| 1 | 0 |
| 2 | 1 |
| 3 | 3 |
| 4 | 6 |
| 5 | 10 |
| 6 | 15 |
| 7 | 21 |
| 8 | 28 |
| 9 | 36 |
| 10 | 45 |
So by attempting to overcome inadequacies in skill level by doubling the number of coders on a project from say, three up to six, you’re potentially introducing five times as much communication. This level of non-productiveness will very quickly erode cost savings. And you’re still left with an application which although functional, will likely suffer from quality related issues over the longer term.
Commoditisation fallout
Assuming coder commoditisation has occurred and the wrong people are left to run wild at the keyboard, there are a number of ways things can rapidly go downhill:
- Required effort to finish tasks becomes high. Seemingly simple jobs become a chore and durations rapidly blow out well beyond what’s required by the competent coder.
- Sustain costs increase either due to buggy software or high degrees of effort required for future changes.
- Customer satisfaction decreases as durations increase and confidence wanes when expectations are not met.
All of these can be damaging for the project and for the organisation as a whole. It can also be extremely difficult to manage the wrong people out of the roles they’re in.
Coders are not beer
Coders are not very fungible and treating them as interchangeable commodities is simply a recipe for failure. The mindset that units of work can be defined and quantified then assigned to any coder and still get a consistent result is borne of a misunderstanding of what the software development process consists of. Here’s what needs to be understood if we’re to avoid commoditised disappointment:
- Coders come from a very broad range of backgrounds and have wildly varying skill levels.
- This varying skill level can have a major impact on both the duration of development and the ongoing sustainability of the software.
- Merely throwing a greater number of less skilled individuals at a problem will not necessarily solve it faster or more cost effectively.
- Software development is a profession requiring skilled practitioners to produce a quality product.
Ignore these at your own peril; I’m off for a beer!
Looking at the path in the image above, you’ll see it specifies the subdirectory “db\transactions”. After inspecting the folder structure of the repository, I found the subdirectory was missing. Comparing it to a newly created test repository I found that not only was the "db\transactions” directory missing but so was “db\txn-protorevs”.
I’m an Australia based technologist and software developer with a general favouritism towards Microsoft gear but love my getting my hands on anything innovative that I can get excited about.