[Series] Experiencing Facts and Fallacies of SE - Stop! No more people onboard

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

"Adding people to a late project makes it later"

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 command split, 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,

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

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

Comments

[Btara Truhandarien]

Funnily enough though in software engineering we think of ourselves as practicing the art of transforming human creativity to machinery logic, we're really bad at finding good measurements for our work. Productivity measurement? Code quality measurement? Contribution measurement? We're bad at measuring them or downright don't know how to measure them!

I don't know how steep the diminishing returns are in software engineering when adding people, but I do agree with you that software engineering is much more than the sum of the efforts of X number of people