Adding Too Many Resources

In 2014, I worked for a not-to-be-named cable company. I was working on their iOS app. It was a universal application (both iPad and iPhone) that allowed the user to browse or view cable assets on the device. A user could also send them to their cable box and watch them on their home television. I should have known something was wrong when the person who hired me quit 3 days after I started. We were at 4 developers after that. The team size was almost mirrored by an Android team, who actually had 6 developers. So about 10 developers for a mobile team. We were trying to release the next version of the mobile app; the first version to introduce video-on-demand and downloading capabilities.

Some members would be tasked with a large chunk of responsibility, and they would essentially be out of contact with anyone else until they had something to show. All of the other developers would just be working on bugs that would come from offshore QA testing over night. As bugs kept being found, we kept pushing release dates, and adding more developers to keep up with demand. Eventually every new developer we brought on needed a sprint to figure out how to work in an area of the app. Unfortunately, the time cost of training the new developers directly interfered with the team’s ability to produce quality code. This resulted in a large increase in defects. In an effort to save time, defects began getting assigned to specific people who had worked in the area, overloading them with work.

By the time I parted ways with the company, that project had 20 developers working on it and not a release in over a year. I heard two months later they had scrapped the idea for a standard architecture, unit tests, and had forced a release to the App Store. Reviews were riddled with 1 star complaints about how many users were unable to even log into the app. This was incredibly depressing for me and I didn’t even work at the company any more.

It is very easy for a team to say “we have too much work to get it done in that timeline”. A simple response to this statement is easy too, “let’s just get more resources to do the work”. Now, this methodology works in several instances.

Things like manual labor, where tasks are very easily broken into multiple pieces. Two laborers can come together and decide which pieces to build and then combine them easily once they have finished individually. This same idea can be applied to development, provided you have the right tools to be able to easily separate work and combine end results efficiently. However, even in cases where you do have the correct tools, it can still be very difficult (or even impractical) to separate a development task into multiple pieces.

This scenario is a problem that isn’t easily visible to someone not submerged in the development. Adding too many resources actually breaks down the process and makes it more difficult to finish. No matter how many men or women you throw into the equation, it still takes 9 months to create a baby. In the end, determining the parent of any complications becomes significantly more complicated.

A new developer has to be taught about the system by a veteran developer, this means both of them are out as they cannot produce anything usable until the new developer is brought up to speed. Being unable to break up a difficult task into smaller tasks that are easily coupled with the other pieces means only one developer can work on that part at one time.