Software Project Misconceptions: More People Will Finish Sooner
Know the software project misconceptions: more people will finish tasks sooner.
Join the DZone community and get the full member experience.Join For Free
More hands will finish sooner. This is common sense that has been applied successfully in many human endeavors, throughout centuries, industries, and civilizations. A practice so popular that can easily result in a misconception due to hidden assumptions, oversimplification, and bias. Employing more people to finish your software project sooner is not always a good idea. Writing code can be a more complex and complicated activity than simple procedural and repetitive work. Using a large employee expansion as a strategy to solve your software project's problems is like testing only a single happy path for a use case with many negative tests and edge cases.
Software Code as a Medium
Software code is a tractable medium. From simple ideas, we can build concepts like objects, interfaces, and behavior into flexible representations of complete systems. Although it's reasonable to assume that this medium tractability will lead to fewer difficulties, coding introduces its own difficulties. Conceptually involved ideas with problematically complex implementation, especially under scaled codebases (e.g., millions of lines of code) require creativity, skills, quality, training, communication, and coordination among employees.
Critical flaws and inconsistencies of our ideas often become clear during implementation. The limits of our knowledge and the limitations of the implementation medium constrain our ideas whilst creating unexpected implementation difficulties. Such difficulties require even more communication, debating, and synchronization, making software projects complicated. Adding more people will not necessarily increase the overall productivity in such cases. If certain prerequisites are not met, more people may have a detrimental effect rather than a positive one. Projects may finish later rather than sooner if not abandoned.
Let's start with a typical division of labor example that applies to any project involving procedural work. For simplicity, a law firm is used in this example. Conclusions apply to software projects too since they also involve some level of procedural work.
Purely Procedural Work
There is a law firm that has to process and file too much paperwork. They decide to hire a clerk to do the job. The clerk is very tidy and all paperwork is filed at the right time and placed on the right shelf. The firm is successful and more work comes up requiring more clerical work. Another clerk is hired to handle the extra paperwork.
Case 1: If the processes for handling paperwork are in place then the clerks can synchronize. Division of labor in this case will be beneficial. It's clear which paperwork is handled by which clerk, how filing is arranged (e.g., in alphabetical order or chronological order) and mechanisms exist for weekly double-checking for filing errors.
Case 2: If no processes exist then the division of labor is likely to introduce problems. Filling mistakes are made. Some of them are never recovered leading to frustration and people being fired. Other mistakes are recovered weeks later leading to delays that may have been avoided had no division of labor occurred. Hiring more clerks created more problems than solved in this case.
One of the most basic management approaches is to add more workers when workload increases and deadlines seem difficult to meet. Even for purely procedural work, more workers will help finish tasks sooner only if the right processes are in place for organizing and effectively synchronizing work. If no processes exist, more workers will increase complexity, introduce errors and will probably make things slower rather than faster. The worst-case scenario could be that a firm made new hires handle the extra paperwork only to be driven out of business.
Similarly, division of labor in software projects requires a level of process maturity where the right processes exist for effectively dividing work among employees. If no such processes exist it may take too much time until the new hires are productive. They may introduce new problems and instead of giving value, they may make things worse.
Salient Features of Software Projects
Software projects seldomly involve purely procedural work only. Creative and procedural work is usually required coupled with the right processes. Creativity is involved throughout the software development lifecycle. From ideas (requirements) and concepts (architectural design), to implementation (coding, testing, and deployment). Each software project and each role (developer, tester, DevOps, product owner, manager, etc.) have a different mix of repetitiveness and creativity. Some projects have more creative work than other projects while for a given project, administrative roles usually have less creativity and more procedural work than roles close to software development.
Decisions When Writing Code
Implementation for cognitive tasks takes extra time and effort. They are not procedural and automatic, they require individual and team thinking. Code writing implies decision-making. There are coding decisions that can be undone easily in light of unforeseen problems. There are also coding decisions that could cost dearly to undo. Big code rewrites, extensive refactoring, redesigns, replanning, and retesting will make initial schedules and plans useless. The entire project falls behind and the addition of more people could alleviate this problem to a certain extent, only if the processes are there. The worst-case scenario could be that the added complexity from the new hires is too difficult to be handled and things get worse.
Another factor that complicates software projects is bias. Although bias can generally have both a positive and a negative effect, failing to fix bias problems while growing in employee numbers is a recipe to be avoided. Creativity and abstraction involve bias. The very misconception that this article focuses on is actually a byproduct of optimistic and overconfidence biases. Technically skilled programmers with a good command of programming languages tend to be utterly optimistic in their skills and talents. Often, this makes them bypass the basic dynamics of scaling and believe that adding more programmers to a project is a panacea.
We tend to blame the physical media for most of our implementation difficulties due to our biases while our own ideas and implementations usually have downsides. When we have a great idea to solve a problem we may be tempted to believe that it's flawless just because it's ours. This is the very definition of bias.
Architectural design bias is one of the reasons that ideas are designed with unidentified flaws. Confirmation bias when writing code is one of the reasons that critical test cases have been missed by development teams. Happy paths have been considered only since lateral thinking has been suppressed by the need to confirm that our work is good. Adding more people may simply add more bias, more debates, more flaws in design and coding, more time and effort to finish the project. The rational decision would be to identify ways of handling detrimental biases and only then make new hires if necessary.
Software projects usually involve interaction with customers. The bigger the customers the more that they may affect our schedules. Customers may want to interact with our solutions, test them and try new things, give feedback, demand features, and bug fixes. Last-minute demands from important customers may also make our initial plans useless and interfere with our internal quality. Although a balance should exist between what our customers could affect (our external quality) and what they should not affect (our internal quality), this is easier said than done. If our internal quality is compromised and our company is not mature enough to handle more hires, a dozen new employees could make things much worse.
Basic Dynamics of Division of Labor in Software Projects
Adding more people to software projects may lengthen the schedule and not shorten it. New hires will need a ramp-up period. During that period they are not expected to be fully productive. If the processes are in place, this period will be relatively short and soon their productivity will flourish. For mature companies, this period will be manageable. Once everyone knows what they're doing, it's the dynamics of task braking that take effect.
A task should not be too small nor too big. If it's too small (e.g., half an hour) then there is a risk of losing focus from the important issues and diverting to less important activities. This means that we have mixed our priorities. If it's too big (e.g., 2 working weeks) then there is a risk that smaller hidden tasks exist that should have been identified earlier. In this case, the big task should have been broken into smaller subtasks. Hidden tasks may bring nasty surprises to the overall project like duplicate work, rewrites, redesigns, and other costly activities. We may want to estimate a project (for time and money) in order to be able to manage it as it progresses. To do that, tasks must have enough detail to avoid unforeseen problems while not losing track of priorities between different activities.
As the number of unknowns, the number of people, and the number of tasks grow, the probability of making an error increases during task braking. Hidden tasks will be identified late, the unjustified effort for less important tasks will happen, time will be needed for meetings to debate, communicate, train and synchronize.
Large Software Efforts
While the probability of a single task going smoothly in terms of scheduled effort may be large, the same probability for a large effort consisting of many tasks may become very small. As a result, it could be safe to assume that we can derive schedules using fewer people and more time. It's not safe, however, to assume that we can derive schedules using less time by employing more people.
Software projects need quality and best practices in designing, coding, testing, deploying, planning, estimating, task management, project management, and people management before they can reap the benefits of drastically expanding in employees. More people will help finish software projects sooner for companies with the right processes in place. Process maturity is vital for maximizing the benefits and minimizing the costs of scaling in tasks, communication, and coordination. Increasing the number of employees is not a panacea. It may make things worse and the costs incurred may not justify the benefits. This is a common reason why some start-ups rapidly grow in headcount only to reduce the number of employees shortly, back to a minimum. Software projects have their own complexities that are not accounted for when simply expecting to add more people to get the job done.
Opinions expressed by DZone contributors are their own.