I first found out about ‘The Mythical Man-Month’, a book written in 1975 by Fred Brooks, sat with Michael Robinson, a former Director at Thoughtworks, now CTO at a very successful app, Snupps. Michael was explaining the core principle of this book using his own team as an example, who are of modest size but producing software with over 1.6 million users. So, I set out to read for myself what the magical secret is in this book that has helped software teams to become so efficient.
The book intrigued me as you don’t need to have a PhD in Computer Science to read it. I think the book owes its success to the fact that many of the principles are simply common sense, and can be applied outside of Software Engineering to any complex project you find yourself on.
As a recruiter, I come across the issues faced in the book numerous times a week – companies calling with panic in their voices, looking to add a dev to their team to save their project running overboard. Or ignoring junior candidates in favour of experience, believing that 10x more experience will get you a 10x better developer, believing that the two are directly linked. Therefore, I thought it would be best to summarise some key points made in the first three chapters of the book:
- The Mythical Man-Month
- Brooks’ Law
- The Surgical Team
Point 1: The Mythical Man-Month
The above is the original ‘man-month’ concept – an idea that suggests, as more manpower is added, the less time a task should take. This model works perfectly for individual, simplistic tasks, however software engineering is anything but. It’s a team effort, consisting of intricate and complex timelines, muddled with cross-team communication.
One reason for this, is that Software Engineering is sequential – you can’t start testing until the code has been written. For example, you can’t have 9 women make a baby in one month. Similarly, 9 software engineers can’t make a 9-month project happen in a month, no matter how well you plan and allocate resources.
So, how do you go about planning these complex projects?
The author recommends the following:
- 1/3 planning
- 1/6 coding
- ¼ component test
- ¼ system test
This may at first seem a disproportionate amount of time towards coding – after all, it’s what makes the product, right? The reason for the minimal time spent on this is twofold – one that the planning should mean this goes smoothly, and that – technically speaking – it’s the easiest to estimate. Also, from speaking to numerous Development Managers over the last year, the best programmers are the ones that write the least code, not the most.
It also may seem a disproportionate amount of time on testing – however Brooks argues that this is both the hardest time to estimate, and yet also the most critical time. Any delays here are closer to your release date – meaning the external business effects are huge and could anger your stakeholders.
To handle this, Dev Managers need to have the courage in front of stakeholders to defend their estimates – software is like an omelette – ruined if cooked too slowly, or too quickly. The stakeholder can ask for it before it’s ready and have it raw, or try to speed it up by cooking it at too high a heat – not what anyone wants in software or omelettes.
Apply to recruitment: Software is sequential – and can’t be sped up by adding more developers to the project. Focus on hiring high quality developers who write minimal code well, and Development Managers that can estimate projects correctly.
Point 2: Brooks’ Law
Brooks’ Law is the concept that ‘Adding manpower to a late software project only makes it later’. The reason for this can be summed up in one word: Communication.
With two developers in a team, communication can only go two ways, however, that gets multiplied by three when you add another dev to the team, and by six when you add a fourth. Take a high-growth team where you’re adding a developer each week, and you’ll soon have so many lines of communication every project slows down.
This is further complicated in software development by needing to bring new developers up to speed on existing projects, and training them in technologies they maybe haven’t had as much exposure to. Even if you’ve brought on someone with exact knowledge of your stack, the smallest differences can make this transition problematic.
Apply to recruitment: Make sure your candidate onboarding is smooth and informative so that new devs can get up to speed quickly and start contributing – and if possible, keep teams small.
Point 3: The Surgical Team
This chapter starts by speaking about the common view that you’d rather have a small, elite team of developers than a large group of average ones. It then goes on to explain how it should be organised, comparing it to a surgical team.
A study quoted in the book showed that between the highest and lowest performers in any given development team there was an imbalance of 10:1 – that being a programmer at one end of the scale can do 10x the work of one on the lower end. Interestingly, this did not depend on experience or pay scale – a trap many of the companies we work with fall into.
In regards to the breakdown of the team, Brooks’ ‘Surgical Team’ of developers comprised of only 3 actual programmers doing the core of the work, in a team of 10. This solves the problem above of communication slowing down a project and shows that in a team 7/10 of your resources should be in place to support those doing the core work.
Apply to recruitment: Don’t fall into the trap of believing the more experienced a developer is the better they are, be open to hiring juniors with the capability to grow into a 10X programmer. Also, ensure your core programmers are well supported in their role to maximise their potential.
There are numerous other points mentioned in the book I could cover off, such as conceptual integrity, the surgical team, and project communications, but to expand on those would need another book in itself…
I hope you enjoyed this very brief summary of an excellent book, and that some of the lessons can be applied to your own projects – software-related or not.