Software Development and Engineering Blog


HW28: Chapter 25

Sam Word | 21 Nov 2017

HW27: Chapter 24

Sam Word | 16 Nov 2017

HW19: Team Progress II

Sam Word | 14 Nov 2017

HW25: Chapter 23

Sam Word | 09 Nov 2017

HW24: Chapter 22

Sam Word | 06 Nov 2017

HW22: Chapter 21

Sam Word | 02 Nov 2017

HW19: Team Progress I

Sam Word | 31 Oct 2017

HW21: Chapter 20

Sam Word | 26 Oct 2017

HW20: Chapter 19

Sam Word | 24 Oct 2017

HW18: Chapter 18

Sam Word | 18 Oct 2017

HW17-B: Chapter 17

Sam Word | 11 Oct 2017

HW17-A: Chapter 16

Sam Word | 08 Oct 2017

HW16: Chapter 9

Sam Word | 05 Oct 2017

HW15: Chapter 15

Sam Word | 02 Oct 2017

HW14: Testing Reflections

Sam Word | 28 Sep 2017

HW13: Chapter 8

Sam Word | 28 Sep 2017

HW12: Mythical Man Month

Sam Word | 26 Sep 2017

HW11: Chapter 6

Sam Word | 21 Sep 2017

HW10: Chapter 5

Sam Word | 13 Sep 2017

HW9: Reflections

Sam Word | 12 Sep 2017

HW8: Chapter 2

Sam Word | 12 Sep 2017

HW7: Reflections

Sam Word | 07 Sep 2017

HW6: Chapter 4

Sam Word | 07 Sep 2017

HW5: Reflections

Sam Word | 05 Sep 2017

HW4: Chapters 11 & 12

Sam Word | 30 Aug 2017

HW3: Chapter 10

Sam Word | 28 Aug 2017

HW2: Responses

Sam Word | 27 Aug 2017

HW1: Chapter 1

Sam Word | 24 Aug 2017

HW0: Introduction

Sam Word | 23 Aug 2017

HW12: Mythical Man Month


26 Sep 2017

I found chapters 1-4 of The Mythical Man Month to be quite interesting, not entirely because I learned numerous new concepts (I did learn a few things), but because Brooks explained in detail several things I learned to be true about software engineering and project management through my own experiences. For instance, the central theme of the book is that “Adding manpower to a late software project makes it later” (Brooks 25), which is something I have observed in small-scale settings. Several months ago, a large feature went into the main application I work on at my internship just a few days before the latest version was sent to systems integration and customer testing. Unfortunately, the complicated logic driving that feature was incorrect, but something about the feature made it unable to be removed from the branch we were using for the next release (I would explain why, but I was not involved in this issue). Many things went wrong in the creation of this feature, but as deadlines approached, our choices were limited, so two developers stepped in to help the original developer. The new developers, who were already acquainted with the larger system, still took more than a day to become familiar with the specifications of the feature. It took several more days to actually get the feature working. In the end, the release date was delayed by about a week. This isn’t much compared to the delays of some projects, but for my team of 9 developers who release new features and fixes every 12 weeks, this was a significant delay for something seemingly small.

Another interesting thing I noticed in this reading was the observation that programmers and project managers tend to be too optimistic about the time it takes to complete a project. I am certainly guilty of this. Over the summer, I took charge over a somewhat large UI refactor of an outdated portion of the application I work on at my internship. I originally estimated the project to be finished in November 2017, including unit testing. Now that it’s almost October 2017, and having experienced several complications, I realized I was probably too optimistic. Luckily, the project is a low-priority project, so the release date can be moved back. In the future, I know to plan for the fact that I, like many other software developers, am often too optimistic.

If there were an easier way to estimate time, and realize that we are often too optimistic, more projects might not fall behind schedule. But, as Brooks explains, this is one of the difficulties of project management that is difficult to overcome. If we underestimate how long a project will take to complete, then it will either be late, or be incomplete compared to the original vision. If we overestimate the time it takes to complete a project, the resulting product may be obsolete come time to release it. He did note, however, that projects tend to follow a set timeline better if at least half of the schedule is devoted to testing since we tend to be the most optimistic about testing and creating bug-free software.

The last—actually one of the first—things I noticed about Brooks’ book was how he consistently referred to programmers, project managers, and other professionals as men. In fact, the title is Mythical Man Month, in reference to the number of men assigned to a project. This didn’t hinder my ability to read and understand Brooks’ observations, but it was certainly distracting. In fact, his only reference to non-male people in chapters 1-4 was explaining that “the bearing of a child takes nine months, no matter how many women are assigned.” This was a good example for tasks that have sequential constraints, it was bothersome that the only mention of a non-male was in reference to a woman giving birth. While this reading assignment was a worthwhile read, I felt as though it was never talking about me or people like me, despite being a software developer. In this book, women are mothers who give birth, and men are programmers, managers, surgeons, etc. It felt as though it was specifically referencing male developers, further solidifying the stereotype that programmers, and professionals in general, are men.