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.

The Mythical Man Month- Chapters 13-15

 

The Mythical Man Month: Frederick Brooks
Summary

Todays week late readings are "The Whole and the Parts", "Hatching a Catastrophe", and "The Other Face".

The Whole and the Parts starts by saying that a good, solid, unambiguous, rigorously tested design is the first step to ensuring there are no bugs. The second step is to think of programs in terms of control structures, more in line with the concepts of structured programming, as opposed to the quite popular (and common) technique of using GO TOs everywhere. It then goes into aspects of component debugging using the phenomenal concept of multi programming. It ends off by going through some aspects and problems in system level testing, giving the valid advice that you generally only want to integrate one component at a time, to limit the scope of horrible bugs.

Hatching a Catastrophe starts with one of the most cogent statements I've heard in a long time: How does a project get to be a year late? One day at a time. It then goes on to say that to ensure a projects success on a tight deadline, the project generally needs to define sharp and unambiguous milestones, such as "Spec signed off on by <x, y, z>". Ambiguous or fuzzy milestones often lead to Ambiguous or fuzzy answers as to completion, which are interpreted by management as "yeah, it's done". Which ain't right. It then goes off to chat about PERT charts, and ensuring that managers are willing and able to whip their team for falling a week behind.

The Other Face talks about the two faces for which a program is wrote: first the cold, dumb, uncaring (except caring very deeply) computer, and second the distant and far away users. While many programmers focus on the computers, fewer focus on the users. Things like half decent user docs fall by the wayside. Apparently the concept of self documenting code kind of starts here, and flow charts were never useful.

Discussion:

1. Why is this paper interesting or significant?

The bit on slippage is interesting, and bears stating to people working on projects...

2. What are the faults of this work?

It seems decent for the time period and context; but that period and context aren't wonderfully awesomely useful today. The idea of a full on spec for most software is a pipe dream, especially when Agile is taken into consideration. I also question whether or not the work is widely applicable today- languages and tools make docs less important. 

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

An unambiguous fuzzy answer is in my future.

XP Installed- Chapter 22-24

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson
Summary
Chapter 22 is Handling Defects. It looks at how defects can be scheduled in (add cards for defects and schedule it in being a very nice way of going about it), that defects tend to remove value from a product/customer. Defects also seem to cluster around points that are painful in one way or another, look into those with a fine tooth magnifying glass.


Chapter 23 is The Conclusion. Oddly, the book chooses to go on for another eleven chapters, but we'll roll with it. Conclusion starts by enumerating the twelve values of XP: On-Site Customer, Small Releases, Planning, Metaphor(?- bad XP folk using non descriptive names), Simple Design, Pair Programming, Collective Code Ownership, Continuous Integration, Coding Standard, Testing, Refactoring, and FOURTY HOUR WEEK. It's just a summarization of the preceding 22 chapters (110~ pages) into a bulleted list. 


Chapter 24, "We'll Try", seems to be an overview of an idealized XP response to an impossible request. Basically, if you've broken down the numbers, looked into it, and feel confident in your estimates, you have all the power in the world to say to management "This ain't gonna happen, we can get part of it done, you decide which parts". It's kind of like a union without any supporting labor law.



Discussion
1. Why is this paper interesting or significant?
The idea of handling defects as a 'task', integrated into the schedule with features and other tasks is interesting to me, as traditionally I've seen them handled out-of-band, and I think that integration is a much nicer and more fluid way of handling them.


2. What are the faults of this work?
Meh. Seems alright. 


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

Forcing management to decide between loved ones (features), like the evil person that I am.

The Inmates Are Running The Asylum- Chapters 3-5

I don't remember if we had color or not... but, why not?

The Inmates Are Running The Asylum: Alan Cooper
Summary

We're readings Part II of Inmates, "Wasting Money", "Dancing Bear", and "Customer Disloyalty". As an aside, Inmates was published in 1999 according to Amazon. I was probably in the 6th grade in 1999. My school still had labs with the old IBM two 5 1/4" floppy computers with Oregon Trail. I feel like things may have changed between then and now. A lot.

Wasting Money talks about how development can spin through a million dollars quickly. And rambles. The core seems to be "management will try to force a deadline, development will say 'ok, but we're cutting these things', management says yes, and somewhere in the middle the vital feature doesn't get coded". This all happens because management through a deadline out, and everyone tried to stick to it. I think. He then moves on to say that iteration is the evil cancer within modern development practice.

Dancing Bear seems to summarize how various categories of software fail, and how they could be made better. I think part of this may also be saying that web applications are a fad.

Customer Disloyalty talks about customers and what the customer wants. Kind of. It starts off by looking at what makes a product "good", ie is it viable, capable of being produced, and desirable to an end user. Desirability isn't something that can be easily retrofitted, and without it from the start the entire software piece wanders into the forbidden territory of god-awful software. He goes on to list 3 companies and how they relate on the tri-axis of good software, and apparently Apple has been known for integrating design for a long time. Who knew?


Discussion:
1. Why is this paper interesting or significant?
It has decent business advice- you don't want to give a user a product that leaves a bad taste in their mouth, whether or not you're the only one that can offer a given product or service.

2. What are the faults of this work?
When I'm reading this book I feel like it's all based on logical fallacies and failures in communication. The differentiation between features and goals, feels like its based on a misunderstanding of features- it feels like he's saying "Ohh yes, your product spec will say 'runs in IE, Chrome, etc', 'has user accounts', etc", when most of the specs I've worked within are more "How is the user going to use the system".

I don't think he has a basis for his statements on iterative development. It sounds like he comes from ye olden times when you spent 2 years in development in a black box and then released... which isn't the case for a lot of software today.

Retrospecting on it, I feel like the discussion of survivors is more tailored to older generation computer users (or... y'know, the majority of users). Basically, the people who didn't have a web account somewhere online by the end of high school. The internet itself is one giant beta testing playground, I feel like it has desensitized us to some issues, and simultaneously exposed developers to much better interfaces.

3. What is the possible future work extending from this work?
THE FUTURE IS YESTERDAY! And possibly better analysis of software with respect to desirability axis; but I don't really feel like this has been anything new.

Edit:
In retrospect, it was 1st/2nd grade that had Oregon Trail PCs... don't get me wrong, it was Hearne, by 6th grade the old computers were still there, but in modern society it was still the days of IE5.5ish and Win98SE.

The Mythical Man Month- Chapters 10-12

The Mythical Man Month: Frederick Brooks
Summary
And now we read "Documentary Hypothesis", "Plan to Throw One Away", and "Sharp Tools".

Hypothesis talks about the idea that a core set of documents forms the core of whats important to management, and furthers my theory that this book is targeted at managers of IBM systems products. To an extent it also looks at what forms this core documentation: What are the objectives, what are the specs, what is the schedule, what is the budget, "Where", and who is involved. Where lists space allocation, and based on all the other horriblenesses of the book, I'm not sure if that refers to office space, or memory space. And it says formal docs are good for communication and decision commitment.

Throw One Away talks about the concept of making an initial pass at a system, which finds many flaws and bugs in thought, and then scrapping it and starting over. The end result is a system with fewer flaws for users to encounter, at a slightly higher development time. The author talks about planning the system and organization for change. Humorous fact: in this section the author states "the problem is programmers have too little oversight from management", and the prevailing trend today is more or less "get off my back/stop micromanaging". He then talks about other things which are decidedly less interesting.

Sharp Tools states that development requires good tooling. A testing machine with at least a million bytes of storage, and a hundred million bytes of disk space is more then adequate. Simulators are useful in new terrain (and when the actual machine is busy), program libraries, profilers, tools, etc. And High Level Languages, while not yet popular (probably due to inertia) are the wave of the future!!!


Discussion:
1. Why is this paper interesting or significant?
Throw one away is an important concept, and seems almost ahead of its time considering how often it comes off as forgotten "Gospel" today.

2. What are the faults of this work?
The wrong people are reading it. Everything they say is wonderfully valid in their time frame and in their work process, but it's just not here today. Have we thought of trying "Pragmatic Programmer" instead of "Mythical Man Month"? Plz? Also, the documentation statements are kind of... fuzzy. In the context they're coming from it's important, but in modern context (applications used by users, rather then programmers), I subscribe to the theory that documentation isn't as important.

3. What is the possible future work extending from this work?
If management sees this, I forsee my development machine being downsized.

The Mythical Man Month- Chapters 7-9

Surprisingly, technology has changed a bit.
This is the computer that this book is focused on.

The Mythical Man Month: Frederick Brooks

Summary

Now we're reading "Why did the tower of Babel fall", "Calling the Shot", and "Ten Pounds in a Five Pound Sack".

Babel is about communication on a large project. Inadequate communication seems to be the root cause for most failures. A few methods are discussed to resolve it. The first is to use a project workbook, basically a massive fully encompassing specification of the entire system, including everything. The second looks at how team organization is handled, with the concept of having a producer (someone responsible for getting people on the same page), and a director (someone responsible for direction). Again with the 1000 years out of date.

Calling the Shot seems like it's about estimating, and comparing estimations to actual performance. It then goes off and says "hey, using a higher level programming language may lead to upto 5x productivity". Srsly? Higher level languages might lead to more productivity then lower level ones? Mein Got!

Ten Pounds looks largely at memory constraints. It states that when building a system, it's important to have both 'operating' and 'actual' limits for size. It's also important to keep a handbook of algorithms with their tradeoffs listed, to keep from suboptimally re-inventing the round rolly thingy.

Discussion:

1. Why is this paper interesting or significant?

It instructs me on how to deal with issues with solutions that are timely and relevant!

2. What are the faults of this work?

Statement 1 was sarcasm. Really. Some of the issues that are being discussed are still relevant (that estimating is always wrong, for instance), but 90% of the discussion is time period specific, and lost on those of us that did not grow up renting out memory on a mainframe.

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

The future work happened yesterday.