Response Article to Hack and Slash

This post is a response to “Hack and Slash”: https://blog.inf.ed.ac.uk/sapm/2014/02/14/hack-and-slash/

 

In the original post, the author talks about software engineering, based on the classic book: [The mythical man-month — Frederick. P. Brooks]. He explains the most common failure in software projects, he then describes two typical mistakes, and finally gives his opinion about how to solve them.

One of the assumptions that the author does is that “increasing the number of people will increase the time and cost associated with project, but claiming the opposite would surely seem preposterous” the first thing that I would like to double check, is that when this situation is described in the book, it implies it is a “running software project” increasing manpower to a late software project makes it later.

This then is the altering of the man-month. The number of months of a project rides on its restrictions. The maximum amount of people hinges on the number of autonomous subtasks. Based on the above, schedules can be inferred using less people and more time. But not in the opposite direction, using more people and less time.

The author also mentions that if there are less things to be tested, there is going to be an increase in the productivity, which is completely true. One of the best critics that the book got, was from Capers Jones, who said that: if you focus on improving the software-product quality, the improvement in the productivity will be a natural result. This is based on some reports on the additional cost required in doing troubleshooting because non-contemplated aspects in the design phase.

Although I do agree with the article in general terms, I have to say that the author just mentioned a phrase: “No silver bullet” which is also discussed at the beginning of the book and is in my judgement, one of the most significant. I consider one of the reasons many companies have been successful at agile development philosophies, because they minimize this difficulty is inherent in systems development. The issues of verifying and validating the system are theoretically fewer when after there is some progress analysing, becomes available a rough prototype for the users, in order to know if the project is on solid ground or not.