This
week I read the first 4 chapter of The Mythical Man-Month. This books is an
in-depth analysis of software engineering. The first chapter of The Mythical
Man-Month deals with an extensive metaphor for large software engineering
projects. Fred Brooks relates large programming projects to “beasts in tar”.
The more the large and powerful beast tries to break free from the encompassing
tar, the more they are engulfed in it. This relates to programming projects,
because the more we try to compact the issue with the programming the bigger
the problem becomes. Brooks states that the reasons for this are: we do not
fully understand the issues before we try to solve them. We think too much of
the program itself, and not enough of the surrounding aspects that come with
coding.
I thought this analogy was very accurate. In programming
II, we had to create a user interface for an educational grading system. I felt
as though I spent much of my time trying to make sure my code compiled fast,
without errors, instead of trying to make a structure that was user-friendly (a
topic that Brooks tackles in Chapter 4). I needed to understand, as Brooks
stated, that programs are just ONE part of the programming system (a collection of interacting programs) and that it leads to a
programming product. I did not see
the bigger picture. However, I think I have matured since then.
I also found the third chapter in the book particularity
interesting. In it, Brooks goes over a model of software engineering roles that
he thinks would work best when trying to conquer large projects. He calls it
the surgical model, because he modeled it after the design of surgeons. These
roles included: a chief programmer, a copilot, an administrator, 2 secretaries
(for the editor and the administrator), a program clerk, a toolsmith, a tester,
and language lawyer. The chief programmer’s job is to design the program, code
it, and write it, and provide documentation. The other roles job is to support
the chief programmer’s job. For example, language lawyer provides advice on how
the chief programmer can produce more optimal code. I completely agree with
Brooks model for positions. When I first read the chapter, I thought that
having a chief programmer do most of the coding would put too much pressure on
that one person. However, as I read on and saw how much the other position can
help, I thought this was a good model. I feel when you have many programmers
focusing on one issue communication can become convoluted. I feel nothing can
get completed is communicate is halted.
The fourth chapter also caught my attention. Brooks goes
over the value of conceptual integrity. As a consumer of technical products, I
feel as though this is an issue that needs to be addressed more in software
engineering. I have used many software products I have felt were not very
user-friendly (ie. Instagram). Whenever I search for something or someone of
Instagram, it never finishes what I am typing. I feel if they worked more
conceptual integrity this product would be way better. Brooks states this
problem can be solved by separating architecture and implementation. I
concurred. If most software products did this, users would not have as many
problems with the interface.
Overall, I thoroughly enjoyed reading the Mythical
Man-Month. I hope we can have the opportunity to red more of it in the future,
or maybe even finish the whole book.
No comments:
Post a Comment