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.

The Mythical Man Month- Chapters 4-6

I think the Empire was a little too effective at
accounting for the Second System Effect.

The Mythical Man Month: Frederick Brooks

Summary:
We're now reading "Aristocracy, Democracy, and System Design", "The Second System Effect", and "Passing The Word".

Aristocracy et al is about the benefits of having a central design team, and how to go about achieving it. I think. Most of the examples within are outdated, and the meanings of terminology have changed so much in past years that I have very little clue what he's talking about. He mentions architecture as the user interface (akin to a clock face), but goes about explaining it in a way thats quasi similar to the current meaning of architecture (internal structuring). The process outlined is inherently waterfall, which may or may not be sensible in the aspect of systems development. Overall he says "systems designed by one person are more consistent then systems designed by one hundred people".

Second System looks at an interesting effect when designing systems. In the first pass of system design it is the designers greatest desire to "Just get it to work so I don't have to go back to food stamps". This leads to certain compromises or design paths that in retrospect aren't that nice. When the designer comes back to design their second system, no longer fearful of entering welfare, they try to integrate all the lessons learned from the first system is the grand, overarching, awesomely powerful successor system. And it doesn't work out too well. The added features don't outweighed by the added complexity and cost to implement.

Passing the Word seems to look at how architects form a single cohesive design, and how that gets passed down to the plebes.


Discussion:
1. Why is this paper interesting or significant?
Second System is an important concept, one that I see in myself (in retrospect), and it is something that would benefit from being more widely known.


2. What are the faults of this work?
It was all written in the last millennium. A lot of whats being talked about was important for the kind of work that was being done back then, but it's since died out. Or, to be more specific, the target population is much smaller today. Are there people documenting the API and architecting Windows or the C# language? Yes. But there aren't a lot relative to everything else, the likelihood any given reader is going to find this relevant has decreased significantly over the years.


3. What is the possible future work extending from this work?
The THIRD SYSTEM!!!!

The Mythical Man Month- Chapters 1-3

One inventory tracking system, coming up

The Mythical Man Month: Frederick Brooks

Summary

This month late reading is looking at the first three chapter of Mythical Man Month: The Tar Pit, The Mythical Man Month, and The Surgical Team.

The Tar Pit serves as an introduction to the book. It starts off by asking why we still see massive development teams if garage sized teams are able to move mountains. The core answer comes down to what is being built: garage teams often focus on a single program, whereas programming armies are often more interesting in systems or products, which have radically different (and more painful) requirements. It then goes into what is enjoyable and what is tar pit like about programming. 

The Mythical Man Month goes into the process of debunking the idea that a project can be quantified in terms of man-months (sort of a unit of wasted life). It states that only if a task is perfectly partition-able (ie its more like a massive group of completely unrelated tasks) can the concept of a man month be well applied. Otherwise it is doomed to miserable failure. 

Finally, the surgical team concept looks at a unique way of forming a team of 10 to increase accountability and decrease lines of communication. It takes inspiration from the concept of a surgical team (as opposed to the concept of near equal distribution in other laboring teams). The team is formed on the concept of having a single person largely responsible for all the work, a second to bounce ideas off of, and a legion of support personnel.

Discussion
1. Why is this paper interesting or significant?
The surgical team concept is an interesting way of dividing up work, with certain nice aspects to it. The mythical man month is basically saying "dont treat man month estimates as pure numbers", which is a valid statement. To an extent, it's kind of like MPG on a car- yes, if you drive 55 on the highway with no stops downhill you'll get 150 mpg.

2. What are the faults of this work?

The surgical team concept ends with one person responsible for writing meaningful code in a team of 10. Maybe 2 if the copilot gets uppity, and kind of 3 with the toolsmith, but not really. I find it hard to believe that that large of a team could be justified for the output of a single individual today. In years past, when they were using punch cards and machine operators (as mentioned in the text), this approach would have made much more sense. But today, with the tool support from modern IDEs and languages, I think that work distribution is unrealistic in its resource underutilization. It also ignores that a lot of programming today is drudge work- effectively connecting lines together.

Also, the man month chapter is based on the idea of having a man month estimate before a project begins. It seems to disregard the factor of individual effectiveness as a means of further debunking the man month concept.

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

Legions of research papers. I would be curious to see how a structure similar to surgical teams would work today, but I'm not sure how such a thing could be objectively tested.