close

Alwyn Jose

Computers

What are the ideas behind the book ‘Mythical Man-Month’ by Fred Brooks

Mythical Man Month Frederick Brooks

The book Mythical Man-Month is written by Frederick P Brooks, Jr. and was published in the 1975. Most of his chapters cover a numerous number of problems related to large-scale programming. This could have been influenced by his work on IBM’s stretch computer and on Operating System / 360 or simply OS/360. The ideas given-off by Frederick are very profound. And, the idea which hits me the most was, from the chapter ‘The Mythical Man-Month’, if you keep adding more software engineers into a project which is already delayed, it will only makes it more delayed.

To give a small insight, let us assume that a project is delayed by two months. A normal managers, or say anyone’s, first instinct at that time will be to add more software engineers into the project to share the work. One would think, this is the solution for this problem. But, Frederick looked at the situation more closely and stated that this solution will only makes it more disastrous. Moreover, he explains the reason behind it, in such scenario’s one overlooks the fact that, these new software engineers added to the project needs to be trained in the first place. This requires pulling out one of the experienced members out from the project to do this task. If this takes a month, the man-months estimated for these new members plus the one experienced member pulled out from the project will go waste.

In addition, the original work now needs to be divided among the new members and the original team members, which will result in losing some of the progress already made on the previous tasks assigned. All these will result in as if no new members were added, and the project will get delayed anyhow.  In the chapter, Aristocracy, Democracy, and System Design, he talks about Conceptual Integrity, where he talks about cathedrals in Europe. Cathedrals in Europe had integrity of their original design, even though several generations of builders has done the work. He emphasised on the fact that, these builders have sacrificed on their ideas about building or changing the design of the cathedral to keep the design it its purest form from the beginning. Likewise, Brooks suggests that it is important for a software to ignore some of the features and just execute one single functionality efficiently, instead of having all the features integrated and cannot do even one function efficiently. Even though the book was written by Brooks in 1975, most of the issues addressed in the book are still some of the issues faced by software engineers.  One of my favourite quote by Frederick Brooks is –

“How does a project get to be a year late ?

… One day at a time.”

read more
ComputersScience

What is Structured Programming?

Structured Programming

Structured Programming in software engineering is as a method to break down a problem into small levels of hierarchical problem structures. It highlights that a program structure must be attained through a constant stepwise improvement. In structured programming, it is generally recommended to avoid GO TO statements, and use nested looping constructs like while loop statements instead. It was Edsger W. Dijkstra who identified the importance of structured programming in 1965. And later on, Bohm and Jacopini, in 1966, demonstrated that any program can be divided into three major control structures which are Sequence, Selection and Iteration.

The main guidelines followed in structured programming while improving the program structures is to identify the major functions early. Secondly, at every stage of the improvement process one must analyse to know all the consequences of decisions taken. Thirdly, be flexible enough to make changes to an initial decision when encountered with an unexpected problem. These small revisions will attribute towards overall improvement of the structure. Lastly, when new data items are discovered during the refinement process, it must be tracked and refined with a new meaning when it must be used.

References:

  • Jensen, RW 1981, ‘Structured Programming’
  • Rouse, M n.d, structured programming (modular programming)
read more