The Mythical Man Month- Chapters 18-19

Space, the final frontier, now accessible
due to blog completion

The Mythical Man Month: Frederick Brooks
Summary

Todays belated blog is for "Propositions of T3M: True or False", and "T3M after 20 years". 

Proposition T3M is just a distilation of the previous 170+ pages into the useful bits, compressing down to 5ish pages. That would have been nice to know in the past.

T3M+20 actually goes back and analyze some of what is said in the context of the past twenty years, looking for what is still relevant today, what may have been misrepresented, and what is wrong. A few interesting things pop out from this, the primary one being that "Throw one away" was suggested in the context of waterfall models, and may be irrelevant / automatically implemented in todays iterative models. It also discusses how the industry has changes; the 1970s were dominated by custom development, where as today (or yesterdecade, to be more precise) it's dominated by shrink wrapped software, either placed on a shelf in a store, or sold directly to customers as an end solution. He ends by discussing software engineering as a discipline, comparing it to the "test and see what happens" form of chemical engineering in WW2.

Discussion:

1. Why is this paper interesting or significant?

It provides a bulleted list of what the rest of the book was about, and provides a quite nice analysis of what's right and wrong.

2. What are the faults of this work?

The only major fault I can pick on right now is that the overview and analysis is getting long in the teeth. It'd be interesting to see how much further it has changed in these past 15 years, and to do a reassessment of "how important is this".

3. What is the possible future work extending from this work?

"T3M today, what has changed, what will forever be the same?"

The Mythical Man Month- Chapters 16-17

Who would want to kill such a cute litt-
OHH GOD ITS EATING ME HELP!

The Mythical Man Month: Frederick Brooks
Summary
Todays belated blog is on "No Silver Bullet- Essence and Accident in Software Engineering", and "No Silver Bullet, refined". 


NSB1 starts with what seems like an intruigingly timely summary of good practices- don't build what can be bought, and a few of the core agile practices, back in the days of time shared computers. It starts by breaking project time down into "essential difficulties" and "accidental difficulties", where essentials are things like "building conceptual models of the system", and accidentals seem to be things like "getting the moth out of the relay" and "actually writing code". By the day and age of writing, accidentals had dropped dramatically in time requirement, such that essentials became the core constraint. The problem with essential problems being the problem is that there aren't alot of ways to make those go faster- the core issues are the inherent complexity of software, painful-conformity to reality, that it's always changing, and that it's almost impossible to visualize. These are things that can't really be solved by silver bullets. A list of potential bullets of silver alloys is then listed, ranging from object oriented programming to graphical programming and program verification. It's nice to see that even back then people weren't holding out on verification to solve the worlds difficulties. It ends with various rather forward thinking suggestions for how to improve life, from not-designing-by-committee to following an iterative schedule.


NSB2 revisits NSB1, presumably around 1995-2000 (only a decade old!). It's a rebuttal of various arguments against the hypothesis of NSB1 that "there will not be an order of magnitude improvement in software in the next 10 years". It ends with this nice quote: "Complexity is the business we are in, and complexity is what
limits us". Which is true on at least 23 different levels.

Discussion:

1. Why is this paper interesting or significant?

In 1986 it set forth a lot of the major principles that we still use today. It's impressive in that "accurately predict the future" way. It also gives us our core job definition "Thou shalt be consumed by the complexity, and learn to shape it, for if thou canst, thou art not a programmer".

2. What are the faults of this work?

A 5x improvement wasn't considered an order of magnitude... when I hear 'no order of magnitude improvements' I tend to think 'it's gonna be about the same', but 5x is merely a (kind of small) constant factor away from 10x. I'd also like to know the precise method of gauging that 5x- it was listed as comparing time to write 1 Cobol program with modern paradigms vs olden-days paradigms, but I would expect that ITS COBOL!!! There may be a yet better tool then Cobol for doing programming.

3. What is the possible future work extending from this work?

I'd be curious to see if they could compare productivity today to that of 2000 and 1990. I'm not sure how productivity could be compared though, given the radically different natures of what was done then vs. now.