Today we’re going to be talking about a topic: can nine women make one baby in one month? Of course, the topic is an analogy, and our main objective would be to discover the main limits and challenges in software development planning optimizations. Before we deep down into software development planning, let’s look at an example of casual planning in everyday life.
Here we need to unload a track with various items. The truck contains 100 boxes of furniture. If that is done by a single person it may take that person, let’s say 1 hour. In this situation, it is obvious for us that if we add another person to the process, then it will take twice less time than it would take for a single person. The planning looks obvious and simple. The more people we add to the job, the quicker and easier it will be accomplished. Let’s now consider another example: building a house.
This work is much more complex and requires multiple steps. First of all, you need to create an architectural sketch, then put in the foundation, then build walls, then establish water pipelines, then install electricity, then put on a roof, and lastly paint everything. Each process may require a unique specialization. For example, electricity can only be done by professionals having skills in that field, whereas establishing water pipelines requires knowledge in plumbing. In construction, they even have a term for different teams, subcontractors. Multiple subcontractors can work for a single contractor to accomplish jobs of different specializations.
Many new project managers who come to the IT industry compare the planning and execution of a software project as if it were a job of unloading a truck. But software projects are in fact jobs similar to the job of building a house.
Software projects require backend and frontend development, building services and databases, quality assurance and DevOps activities. Every team can have their own specialization and be dependent on each other’s jobs.
Now let’s compare unloading a truck and building software in a direct example to show the difference in practice.
Let’s start with two people for unloading a truck and seven people for developing software. First of all, we can notice that having seven people on the software project requires them to extend the timeline seven times because they only can do their job when the previous dependent job has been finished. For example, a QA engineer can’t start their job if the backend and the frontend engineers haven’t finished development. Secondly, we can see that those people can only be engaged at particular times when they are required to do their job. That already makes the planning process and execution dramatically different here. But let’s take a step further. Let’s double the number of people who do the job.
We can see that in the truck example, it clearly results in a faster timeline. Let’s look at the software project. The timeline still improves as different teams that have more people can do the job much faster. Let’s double the number of people one more time.
For a truck, having eight people on a job clearly results in a much faster timeline. Let’s look at the software development project. Here we can see that although we have doubled number of people, the timeline may not change so dramatically. The reason for this is for a simple software project, two people can be more than enough to do software architecture, while for QA engineering or business analysis, it can be more beneficial to have more people. So, the new people will be mostly idle for most of the jobs. At the same time adding them to the work will require communication and coordination to explain the context for their activities and provide updates about the work that the other team members have already completed, thus increasing the effort and cost even more.
The practical example I’ve just demonstrated is proven by research. For example, there is research on how far you can optimize the software project without major risks to delivery. There is even a term for it called “The Impossible Zone“. The term essentially defines the compression limit of 25%. If going beyond the limit, the project will almost certainly fail. That means if you have a project for 100 estimated days you can only compress to 75 days maximum by adding people or paralleling jobs.
Another research shows how adding more people to a single team can affect performance. When adding team members beyond pizza size of 5, the communication between them will require more effort while the calendar days output will not improve or may even degrade. In that situation of adding more people to a single team of five, you may be even paying more with poorer outcomes.
All of that shows one thing. It can be tempting to simply hire more people because it is a visible action taken to resolve the issue, but this does not alleviate the systemic problems in planning that are at the root of numerous failures we see nowadays in the software projects. When planning for software development, one needs to learn project specifics and team specializations, understand how jobs can be paralleled and optimized and where it cannot. It is very hard to build a schedule by keeping all these parameters in mind, fortunately you can use tools like Deep Planner to automate most of the monotonous work and build quality schedules in a quick and easy way. Check out the article on Decomposition with Deep Planner to learn more.
For the more context please also check out the video version of this article:
