So, based on our Dubious Axiom, lets move forward to the first observation: Communication Costs.
Lets imagine you are starting a new project, and you can choose to hire one Sr. Developer who can do 2HM at $150K, or 2 Jr. Developers who can do 1HM each for $50K each. If you believe our Dubious Axiom, and economics, 2 seems better than 1. Save that $50K, and buy a pooltable for the office or something. Seems like a deal, right? It’s not.
MMM Says: Steady State Communication Costs
Chapter 1 of The mythical Man-Month is ‘The mythical man-month’ Which covers the fact that communication costs. Those two developers need to communicate. From a decade of observation, it looks like communication between teammates takes about 2-5% of each persons time, per teammate. Which is to say, having 3 people on a team (3 team-mates) makes 4% – 10% communication costs. 4 team-mates? 6% – 15%. See where this is going? So already, hiring those 2 jr. developers will set you back 0.04 to 0.10 HM, just from the start.
Far Says: Steady State Trusts Costs
Something modern economics talk about, and I see daily, is that trust costs. A developer that you trust 100%? They take maybe 5% of time to trust. An occasional check-in. Drop that trust level to 90%, and a manager starts to need to check in at least daily. I think a decent rule of thumb is you lose 5% of a managers time for each 10% of trust you lose in a developer.
MMM Says: Ramp Up Costs
Another part of Chapter 1 talk about how ramp up costs. Imagine you have a project that is 8HM behind, you have 2 hackers on it already. And you have 2 months left to do it. Seems you could throw 2 developers on it, doensn’t it? (2 + 2)*2 = 8.
Well, that doesn’t work. It never will. Software development is a knowledge system, so at the *very least* the two new developers are going to need ramp up time to get up to speed on the project. So maybe if you throw *3* new developers on it! That might work. But, the sad truth is that each new developer needs to be taught, corrected, and updated. So even then, your original 2 developers are going to have a time-sink to get your new developers up to speed. I’m guessing that it takes 20% per new developer for a month or two to answer questions, help fix problems, and in general just get someone new onboard. Hence Brooks’s Law: Adding manpower to a late software project makes it later.
Far Says: New Developers Develop Bugs
Also added into this is that new developers develop bugs. Even the most ingenious developer with years of experience will introduce bugs in their first weeks on the project. Code is the territory, documentation is the map, and even a great developer will bump into odd edge cases, unexplored ally’s, or will mis-use a design that is good, but not intuitive to them. So I’m going to add another 10% overhead cost for adding new developers, just to hunt down bugs/problems/issues they’ve added and to correct them.
Theory 1, aka Brooks’s Law:
Adding manpower to a late software project makes it later. The new hacker, even if she is a genius, will introduce bugs, need face-time, and in general slow down development for several weeks, to months, as they ramp up.
Theory 2: Cooperation costs
Communication, Trust, and teamwork carry overhead costs. As a team, relay sprinters in the 4×400 can beat a single runner doing a 1600 yard sprint. But they need months of practice to do it. A software team isn’t much different. Even accounting for Disorganized Effectiveness, working as a team costs.