Skip to main content

One Pager - The Mythical Man-Month -- Brooks

The Tar Pit


There is good and bad in large system design and implementation. They are what keeps us going. Creativity of design and programming and the need to be perfect every time.

The Mythical Man-Month


Estimating is hard and futile. Disasters are common. (1) estimating is poorly developed and predicated on ongoing success. (2) confuse effort with progress. (3) monitoring is poor. (4) schedule slippage is expected. "adding manpower to a late project makes it later". "The number of months of a project depends upon its sequential constraints." and the resources needed to implement them.

The implementation formula for planning, coding, testing(component, system).

The Surgical Team


A similar observation to Agile; a wide variation between good and bad programmers. In a surgical team there is specialization.

Aristocracy, Democracy, and System Design


The design must come from the mind of one or a small group. The implementation by many.

The Second-System Effect


The second system is always over designed.  It's an important exercise to design and learn from but not implement.

Passing the Word


Make sure that what the designers describe is actually what is being implemented.

Why did the Tower of Babel Fall?


Failing to communicate with a large team. In modern concepts we'd be talking about internal blogs, wikis and webex. Effective communication is key in terms of timely, content, and complexity.

Calling the Shot


Through a lot of programmer productivity research and data collection... Portman, 50% of the projects take 100% more time. Aron and Harr, separately confirm that productivity is relative to complexity. OS/360, confirms Aron and Harr.

The more interesting data was from Corbato, productivity  is constant in simple assignments. Productivity is increased as much as 5x in suitable high-level language.

Ten Pounds in a Five Pound Sack


"Like any cost, size itself is not bad, but unnecessary size is." In today's GEM happy Ruby and Rails programmers just install whatever they need without thinking about this. Deep dependencies have a high cost.

The Documentary Hypothesis


Project documentation may feel like an unnecessary burden but it's crucial. It's a contract from the design to the implementation. It's a contract with the stakeholders. It's a contract for the testers. Format and consistency is important.

Plan to Throw One Away


"in most projects, the first system built is barely usable" So the real question is when do you throw away the prototype. "plan for the system to change", "Plan for the organization to change".

Sharp Tools


This chapter is a little dated but the message is still the same and important. You need tools to be effective and efficient. Whether it's a Wiki, Blog, Bug tracking, continuous build, integration and deployment. You need the best, or at least good, tools.

The Whole and the Parts


Develop a roadmap, validate the roadmap then start building the road. As the system takes shape test and debug the smaller components. Assemble or integrate the components one at a time with scaffolding.

Hatching a Catastrophe


It is easy to recognize major failures that prevent a project from being completed. A building fire or a crashed system are easy. The difficulty occurs when there are minor daily events in life that cannot be made up and harder to recognize.

The Other Face


This is the deliverable. Of course there is the UX for the actual deliverable but then there is documentation, flowcharts, help. The current view

No Silver Bullet - Essence and Accident


The largest chapter so far dedicated to "no silver bullet". There have been a number of improvements from object oriented programming to code generators. None one is significant enough.

"No Silver Bullet" Refired


There has been some new research but essentially the author's position in unchanged.

Propositions of the Mythical Man-Month True or False?


If you do not want to read the book because it's too detailed or long and this doc does not provide enough info, then this chapter is for you. It's essentially a recap of the book based on today instead of 1975.

The Mythical Man-Month after 20 years


If, however, you are more interested in what might work or where Brooks admits he was wrong. Management must act deliberately and with purpose. You must have an architect for conceptual integrity. Second system has some conflict. He never considered the modern GUI desktop. It was too simple to say throw one away. It's more than that. Incremental build is good (a not so modern tool). Information hiding is good(info shared between teams). There are a number of other reversals in this chapter.

Comments

  1. [...] personal experience but someday it may all be regarded as false. For the moment I’ll keep my one page summary as the summary I might use when my intuition checks out. Share this:Like this:Like5 bloggers like [...]

    ReplyDelete

Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: http://www.eeti.com.tw/drivers_Linux.html (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the setup.sh answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).

TL;DR;

I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…