Response to “Hack and Slash” by s1371464

Introduction

This article is a response to Hack and Slash by s1371464.

The author of the article states that, based on his or her experience, it’s possible to save a late project by reducing the number of developers in the team, and claims that this is a preposterous but real proposition. I agree with the author’s proposition, but would like to clarify and explain the statements made, showing why the proposition is not preposterous at all.

Brooks’s law

The author states that the reasons for the project failing to meet the deadline, were:

  • too many developers assigned to the project;
  • a large code base consisting of heavyweight components.

Both of these are simply the consequences of Brooks’s law, as presented by Frederick Brooks in the book “The Mythical Man-Month”. Brooks’s law can be summarised as: “adding manpower to a late software project makes it later” – that, although the work to be done can be split among the new developers, the complexity of coordinating and merging all of the work will slow the progress of the whole project down.

Too much manpower

This simple law also applies to the situation detailed in the original article. The planning and estimation for the project were done inadequately: there was too much manpower assigned to the project from the beginning. The law is supposed to be applied to projects which are late, and obviously the project mentioned in the author’s article could not be late on the first day of its existence, but over time the unneeded complexity of coordinating work among a large number of developers clearly caused the project to miss its deadline.

The main factor of the Brooks’s law is communication overhead. With more people working on the same project, it takes more time to figure out where your place in the project is and what others are working on. Clearly, this was slowing the project down, as cutting down the team much improved the outcome.

Code base size

The other aspect discussed in the article, that caused the project to miss its deadline, was flaws in the project’s architecture. Namely, the software consisted of heavyweight components and the code base of the project was too large. This is also a consequence of communication overhead. As maintaining many inter-relationships across a large team is hard, developers tend to cluster into smaller groups which end up responsible for only a specific component of the project. Developers are well aware on what everybody is working on inside that cluster, and they believe they do not need to care about what is going on outside their own circle. Unless there are some pre-agreed notions about the architecture of the project, each of these developer clusters ends up building a very heavyweight component, to the extent that different teams sometimes end up with different implementations of the same functionality.

Conclusion

The problems that the author encountered are clearly the consequences of Brooks’s law. Projects with too many people assigned have a large communication overhead, which results in missed deadlines along with a flawed architecture. Since Brooke’s law is a well-known software development principle, I do not consider the author’s proposition to be preposterous, but just a simple observation.