[Series] Experiencing Facts and Fallacies of SE - Stop! No more people onboard
Tags: career, softwareengineering, series, discuss
Published: 2018-09-17 22:32:56

---
title: [Series] Experiencing Facts and Fallacies of SE - Stop! No more people onboard
published: true
description: When you're nearing the project deadline, and you cram people in, you get bad results
tags: career, software engineering, series, discuss
cover_image: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQ-JxdI3fmdwrQMd9pnCsoUspvK6LG_NxFS9sbTemXaHq21JzBm-A
---

_**Note**: This post is based on fact #3 of the book 'Facts and Fallacies of Software Engineering'"_

<blockquote>"Adding people to a late project makes it later"</blockquote>

Back when I was working, I had this one big project that I was assigned to do alone. I was the lead system designer and developer. The project was relatively big for a single person (at least in my team), my best guess estimate back then was that the project can be done in _~4.5 months_ time (from scratch to finish). But there was a catch, I expected at least two people to come in and help me out with a few things.

After a couple of discussions with my manager, it was decided that one of my colleagues would come in to help me build the frontend early in the project, and another to come in later on to help out for the backend. Let us call the early colleague E, and the one that comes later L.

Fast forward to 3 months later, L started to come in (by this time E was no longer working with me). I had a clear vision of what he ought to do, which was to build one of the components of the system which acts as an intermediary between 2 other components. It was really quite a simple system, what he had to do was create a program that reads a file and splits it up into several smaller files. If any of you are familiar with the [bash](https://www.google.com/search?q=bash%20shell) command [split](https://ss64.com/bash/split.html), the program was essentially similar, just that it also had to communicate with the DB a bit.

All in all however, the program is simple enough except, the complexity of a system isn't merely a sum of the complexity of the programs. Which also means that the complexity of a project is not merely the sum of the complexity making those programs.

It took quite a bit of time, and a bit of back and forth between me and L in order for him to get to what I deemed an adequate understanding of how the components work in the system and the design of the system. It also took some time for me to explain the designs and code quality that I want to push through. Basically,

<blockquote>The result is that the new team members are very slow to contribute anything to the project at all</blockquote>

Now to L's credit it wasn't _that_ slow for L to come to understand the overall project design. Nor was his involvement in the project cause the project to overshoot its deadline. Moreover it wasn't that his involvement late into project deteriorate the quality I envisioned for the system. But it does make me wonder, was L actually required to be involved?

Because after L finished his part, I still had to look back to the code he produced and had to modify some things. Some related to code design, some related to minor logic corrections, and others related to testability. Had I just created that component myself (or actually had L joined in sooner to the discussion of the project), would I actually have saved that time taken to fix up that component?

I might have been able to... and if so wouldn't I have finished it sooner than my estimation? Did this make the project "late"? Not even time can tell