Good evening everyone! This post is an observation the first four chapters of the book The Mythical Man-Month by Frederick P. Brooks Jr. I am currently reading through the rest of it. It is a series of essays on software design and engineering. If you get the chance I recommend giving it a read!
This chapter is an overall commentary and introduction to the topic of large scale software development as a goal to be conquered. Brooks makes a very good point comparing software productions through his description of the costs of different types of software endeavors. The reason a programming systems product is such an investment compared to a software product is because of its full realization as a piece of software. It not only functions, but it functions correctly. It is highly integrated with other pieces and has capabilities to be improved and modified as need be. It becomes something dynamic as opposed to a static program.
There are a few points being adressed in this chapter however the largest one is the attempt to point out misunderstandings of work delegation in large scale software development. Large scale software development intrinsically has complexity that makes throwing man-months at a problem that is off the rails an expensive process. Brooks' point does make sense and I agree with his points. He also brings up the rule of thumb that half of the time devoted to a software task should be spent testing. I think anyone with any programming experience would probably agree with him on this point because we have all at some point ignored this and then spent double or triple the time going back to fix our mistakes.
After stating the problems of man-months miscalculations, Brooks dives into how to properly organize and delegate employees for large scale software products. He cites Harlan Mills with the idea of the software version of the surgical team where there is a team of highly interconnected and specialized employees that work in close tandem to create a homogenous unit to tackle their part of the job. The key take away from this chapter is that this structure unifies the team in solving a single issue and has a self contained higherarchical structure. These two qualities act like force multipliers to getting the job done and doing it in a more consistent and less error prone way.
This chapter is another highlighting of the critical importance to ensure proper planning of a software before starting fully fledged implementation. This is shown through his discussion of conceptual integrity and aristocracy vs democracy in design, and on both points I fully agree. When handling a large scale software project, there must be some blueprint to constrain implementers in their freedoms. This is a core principal to ensure consistant functionality of a codebase, so it stands to reason to take this abstraction one level higher to the actual design of the architecture as well. What naturally follows from this point is touched on in his discussion of aristocracy in design. Because of the necessity of unity and conceptual integrity of design there must be a higherarchy where architects dictate the models and core principles of a design to implementers. These points make sense in the context of large scale software development but I believe that these core tenents hold true for smaller scales as well. Blueprints, designs, constraints are all tools that help an implementer structure their tasks and thoughts about the product in a consistant manner.