“For every complex problem there is an answer that is clear, simple, and wrong.” – H. L. Mencken

Software development is a complex system of interrelated entities. In this scenario, the common short-term approach and sticking plaster solutions cause more problems than they solve.

The short-term solution cause problems that will appear later (after a delay), in some situations the cure can be worse than the disease.

the short-term symptom fixing approach of software projects results in problem shifting and project failures.

Software development is a system of subsystems.

Cats in Borneo

Watch the video. It’s an entertaining few minutes — Systems thinking: a cautionary tale (cats in Borneo)

The Dayak people of Borneo had an outbreak of malaria. They called the WHO (world health organisation) who sprayed DDT (insecticide), which killed the mosquitoes and fixed the Malaria problem.

DDT fixed the malaria problem, but this solution created other problems in the system.

Roofs collapsed!

DDT killed mosquitoes and wasps. Wasps feed on the population of thatch eating caterpillars. Fewer wasps meant more caterpillars, the hungry caterpillars dined on the roofs.

DDT affected other insects, a food source for geckos. Geckos weren’t affected by DDT but it killed the cats who ate the Geckos.

The cats were the predators of rats and controlled the rat population. The reduction in cats leads to a growth in rats.

Rats multiplied fast and ate the grain stores and spread the plague. The Dayak people got on the phone to the WHO saying we have a new problem.

The WHO put on their system thinking hats and parachuted cats (incredible image) onto the island, which controlled the rat problem and the plague problem.

Operation Cat Drop has its own wiki page! When the solution to your problems is parachute cats out of a plane, it’s a sign the problem has got away from you.

The solution to the Malaria problem caused future problems because the solution affected other areas of the system. Systems are made of up interrelated entities, changing one entity affects other related entities.

Adding more developers — Operation developer drop

Software development is a complex system of sub systems. When you change an input in the system, you may get unintended consequences. Why Delayed Feedback Loops Create Low-Quality Code in Software Development.

Adding more developers is usually a reaction to missing a deadline or is falling behind. This tries to fix the symptom, not a root a cause.

• What is the cause of the project falling behind?
• Will adding more developers fix this problem or make it worse?

If you don’t tackle the cause of the project falling behind, then adding more people won’t fix the problem and could make it worse (it will definitely cost more).

Like the Cat’s tale in Borneo highlights, changing systems is not linear activity, what will be the effects to the related entities if I change this one part.

When considering a change, think about the system, interactions, and dependencies.

The leadership of the project want the problem fixed ASAP, so they added 10 more developers to the existing 20 developers. In a simple world this would increase software output by 10 developers and 50%.

In software developer trying to go faster can cause the project going slower. Unless the fundamental structure and processes of development are setup up, it will just create a bigger mess.

In the real world, this happens

There is a delay in getting 10 developers

10 developers take a month to get accounts, access, up to speed with the project, get to know people on the project. For the first month, the developer output is 50 percent productivity. Leadership wouldn’t have estimated this into their plans, so we are already behind.

For the first 1 to 2 months, the new developers slow down your existing senior developers by asking lots of questions, making mistakes, getting things wrong.

The quality of the work is likely to have more bugs and problems for the first two months, why they get up to speed.

More developers will increase the communication overhead, more developers will ask more questions and more time communicating what’s been done and what needs to be done.

Can the work be split? If you have separate unrelated work, then you can add more teams and they won’t affect each other, e.g. Case management and sales or a separate integration or an app to raise tickets.

Individual features of software are usually linked/dependent on other parts of of the system.

Multiple teams of developers will likely work on connected/dependant features and they need to be in sync. The more developers you have working the more likely they are to break each other's work.

Software development is a loser’s game and faster development comes from reducing the errors you make. More developers will create more bugs, mistakes and errors.

The effect of these with a larger team can be too slow the team down e.g. break the build, break a key part of the software. Newer developers on a project will make mistakes due to their inexperience of the software created.

And then what?

The other area to think about is development standards. If the development standards and practices are not good then adding more developers will create more technical debt and create it faster.

Technical debt will slow the project down as the code base becomes harder to work with and takes more time. Adding more developers if the standards are not good will accelerate the time technical debt will become a significant problem on the project.

In second order thinking you think about the system effects when you say and then what?

e.g. You add more developers — and then what?

• You need to onboard the developers using senior developers — and then what? senior developers output will drop
• More developers will create more software — and then what ? — the testers will be overloaded.

Limits to growth

Software development is a system, if you increase developers, you need to increase parts of the system that are dependent. e.g. if you don’t increase the number of testers, then you are likely to overload the testing capacity on the project. Adding more developers will not create more software ready for production because it won’t have been tested.

Software development can be seen as a system of systems that work as a whole system.

BA’s/functional consultants

Requirements →clarified by Dev, Testers, Customer SME’s

Developers

signed off requirements →software (created from signed off requirements →devs

Testers

Deployed to QA →tested agaisnt requirements →bugs (back to devs) or finished software

User testing

Test scripts (against requirements) → Finished software → bugs or ready for production

other teams/sub systems

• Trainers
• Data migration
• Integrations
• Users/Go-live

Do you have enough senior developers to code review the code of the new developers? If not, finish code will sit waiting for review or bypassing code review leads to a reduction in a quality (and technical debt up).

Will additional developers overload other systems or individuals, such as scrum master, project managers, testers, trainers etc?

Software projects are built up of multiple teams, will they all finish at the same time? In one project I worked on, the development teams finished their work, but the project couldn’t go live until data migration was ready. Data migration was 4 months behind schedule and over half the development team had to released from the project.

The big limiting factor to developers output is requirements ready to develop. If there isn’t an increase in requirements, then adding the developers won’t result in more software being created. Most projects struggle to keep developers fed with quality requirements.

A common cause of slow development is missing or incorrect requirements. Every time a development team creates part of the software, it creates an explosion of requirements and the development team gets stuck waiting for the missing requirements to be defined or requirements are changing.

The start/stop development of poorly defined requirements, slows development and breaks project plans. Adding more developers to this situation won’t create software faster.

Conclusion

Adding more people in a simple world would increase the output of software created. Software development is a complex system and you need to think about limits to growth.

Adding more people is the quick thinking, short term solution that treats the symptom. It rarely results in the increased output in software because it doesn’t tackle the real problem and comes with additional overheads.

Today's short-term solutions create tomorrow's problems. It’s shifting the blame, using a whack a mole approach. We apply a quick fix (whack a mole) and think we are done.

Everything is connected to everything else. Solving problems needs a long-term approach which considers the system as a whole and not an individual problem.

Otherwise, you end up parachuting animals to fix your problems.

Further reading