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.

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.

The Inmates Are Running The Asylum- Chapter 1-2

The Inmates Are Running The Asylum: Alan Cooper


Summary
These chapters start off by giving an introduction to why interaction design is important. They list ~5 examples of where an existing physical system had a computer integrated into it, which subsequently lead to great heart break. It was a decent introduction to why this is important.

Chapter 2 felt like it ran off into the deep end with the constant "It isn't the users fault, it's all the programmers, those mean, evil, no-good programmers". More specifically, it felt like it was treading into a world of idealism, where programmers do have this magical ability to make wonderfully and remarkably usable software, and they choose not to because they enjoy a certain amount of challenge. Or because they're used to working with computers and don't quite see things the same way a user does. And how we're creating unemployable masses because the masses (of poor socio-economic status, thus making us elitists) can't figure out how to use Word.

Summary: Chapter 1 was nice, Chapter 2 felt like he was channeling Don in all of his reasonable and not-complaining-ness.

Discussion
1. Why is this paper interesting or significant?
It makes a case for segmenting the design of interactive (software) products into interaction design and program design, showing that the people who do program design don't necessarily think the same way a user does.

2. What are the faults of this work?

It comes off as combative, which if it's intended to sway the hearts and minds of programmers, probably isn't the best approach.

It makes a lot of statements as to potential job loss because a person can't use a computer to a half competent level... to which I question "What have you been doing these past few years?" For the past many years high schools have required courses in basic computer use, and before that were courses on type writers. I'd argue that the people who are actually employable (/would be useful at a job) can learn to suffer through the infuriating computers that we interact with on a daily basis. While I don't question that software as is today can be quite painful for the new folk, I do question the statement that we're reestablishing segregation.

I'm also forced to question the realism of some of his suggestions. While they aren't bad (having a file system specific to word so you don't misplace files, etc), they seem to require a redesign of the computer itself as we know it- documents need to be shared between applications (emailed off to the PR department), and that level of interaction, to be useful, would need to be integrated across most of the programs the user uses every day. To an extent you can these in the new mobile platforms (iPad), but to see it in the desktop world you'd need to re-implement and integrate on the order of every program your computer-illiterate staff use.

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

Reading on further to see what other fun and enjoyable things he has to say about programmers.

XP Installed- Chapter 19-21

Bugs happen, schedules slip, no need to over react.

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Summary
Today's XP reading is ostensibly on steering. Steering go-carts, iterations, and releases. Primarily it says that "Steering feels good", "Estimation and Steering go hand in hand", "Estimation is important". It feels like a retreading, again, of the chapter(s) on estimation, delving into the role of the person that keeps track of how poorly the team is performing. 


Discussion

1. Why is this paper interesting or significant?

It discusses some empirical evidence for what does and doesn't work for tracking, including "the exercise is kind of useless if the folk aren't honest, so the tracker needs to be non-intimidating"; mentioning the people issues is a rather important step. 

2. What are the faults of this work?

I feel like it puts too much emphasis on reaction to slipped estimates... "OHH DEAR GOD!!! YOU'RE GOING TO BE 30 MINUTES LATE? THE HORROR!!! WE MUST GET OUR BEST MINDS HERE TO FIGURE THIS OUT!" It feels like a violation of the "estimates are just estimates" principle, and the reaction seems like something that's inherently threatening/intimidating. Sure, at some point someone should ask "would you like an extra set of eyes?", but to make it SOP is going to far. So says I.

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

I shall steer our project to the moon, hit the stars, and then lacking sufficient thrust to escape the gravity well our project shall splatter impressively into either a star or the ground, whichever comes first.

XP Installed- Chapter 16-18

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson


Summary
Today's XP reading covers "Do's and Don't's", "Experience Improves Estimates", and "Resources, Scope, Quality, Time". 


"Do's and Don't's" is a bulleted list of "do this", "don't do this", with some minor justification for each item. It's kind of a summarization of the important points of the previous chapters- do things that have immediate effect, don't do things that are useless. 


"Experience Improves Estimates" retreads a previous chapter in that it basically says "the more you estimate things, the broader an experience set you have by which to compare and estimate new tasks". It's nothing new. However, I was glad to see that they brought up "not all tasks can be compared- a database fix and a javascript issue may both come out to 4 hours, but that doesn't mean that by doing the JS issue you can estimate a different DB change, which I was going to pounce on and tear them apart for on reading the first paragraph of the chapter.


"Resources, Scope, Quality, Time" is a chapter that basically talks about "How do I present what I'm doing to the employer", making it one of the worst named chapters yet. The chapter gives a large number of example graphs and when you'd use them (use this towards the end of a project, this can be informative mid way), and ends with the advice "don't get too deep into metrics- while interesting, they don't contribute to the bottom line."


Discussion

1. Why is this paper interesting or significant?

16+17+18-(19-10) = 42, a significant result. It also has that last bit of advice on "Don't get too deep into metrics... we know you're a computer sciencey guy that likes numbers, but, really, you'll get lost". That seems interesting and useful.

2. What are the faults of this work?

I disagree with their statements on "Don't build for tomorrow". While they do have a point, there's a point where you cross from reasonable future-fore-thought to YAGNI violation- before that point you're decreasing future work, and after that point you're spinning you're spinning your wheels in the mud. But, the statements "It's almost always easier to add in later" is just... painfully, wrong. There are a few times where in it doesn't matter, but in general I've found that 'nice simple design' doesn't meld well with 'simple design for complex app'. Logic ends up in the wrong place, or in the wrong conceptual map, such that work is increased. Not to mention, failure to look forward also introduces compatibility issues. In my line of work, we're continuously releasing control software, but we don't make breaking changes to certain things for fear of losing reverse compatibility, meaning at design time we needed to ask "What do we expect to see". 

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

I shall makes charts about how well received our progress charts are received by the customer.

The Design of Future Things: Chapter 6

Feel that rattle? I don't think
it's supposed to feel like that...

The Design of Future Things, Donald A. Norman

Hip-hip-hurrah, hip-hip-hurray, my oh my what a wonderful THANK YE FLUFFY GODS THAT IT'S FINALLY OVER.

Also Dann, los geht's!

Summary:

Todays reading looks at communication between human and device, looking more at feedback from machine to man. At the core, he states that good machine communication means "seen but not heard", if I don't want to talk to my machine, I should know its alive, not dieing, and I shouldn't need to stare at it and open a dialog to determine these things. He restates for the fifth or sixth time that many devices are designed with non-natural indicators, and that when an error occurs, it's generally the poor hapless device that is blamed. He then details a few interesting occurrences within the field of handwriting recognition where-in people actually learned to blame themselves (and hopefully modify their behavior), rather then the technology, because they had a sense of "okay, this is why the machine isn't understanding me". He talks about natural mappings and cars. Which I won't go into again. Then he summarizes with the six rules that you should have learned from the previous 2000 lines or so worth of reading:

1. Provide rich, complex, natural signals
2. Be predictable
3. Provide a half decent conceptual model
4. Make the output understandable
5. Provide continual awareness, without annoyance
6. Exploit natural mappings to make interaction understandable and effective.

That is the book, summarized into 6 sentence fragments. I would have much preferred this with 10-20 pages of meaningful expansion. But that's me, and I'm not the professor.

Discussion:

1. Why is this paper interesting or significant?

It's the last one! It also gives a concrete example of where erroneous output leads to an implicit modification of user behavior- because that systems errors are based more closely on a drawing space then statistical inference, the user can see "Hmm, my g's look like m's, I should fix that". Which is an intriguing case study.

2. What are the faults of this work?

Early on Norman discusses lights as an arbitrary indicator of whether or not a machine is working, citing the fundamental disconnect between light and machine state (requiring a manual to determine meaning), as opposed to naturally generated sounds coming from mechanical machines. The problem with this is, when you're first exposed to a device, you have no earthly idea what any of the sounds mean either. You can say "ohh, hey, it's doing something noisy now, that means its working", but when first introduced to a device, you learn what the sounds mean. You do the same thing when introduced to a device with light feedback, "I plug it in, ohh, hey, a red LED, that must be some sort of power or charging light; I press a button and a light comes on and, after a minute shuts off. But Look! My ramen noodles are now edible. That light must indicate the magicy machine is making things edible". You learn what the indicators mean by interacting with the device, same as you always would.

He says at one point "People need to be kept in the loop" but never really specifies why. If a machine breaks that the person is responsible for, why yes, that person needs to be in the loop. If that machine is expensive and its breaking could cost lives, then yes, really, that persons need to understand it inside and out. If it's a coffee machine, or an upload, all I really want to know is "is it done", and maybe "is it even working", and that's the extent of how far I want to be in the loop. Which is to say, there are locales of where these things are and are not important.

Basically, at the core he ignores "different situations call for different thinking", and part of this stems from the fact that he never specifies a domain for his advice- clearly it's all coming from his need for smarter cars, but when it's applied to coffee makers, web sites, and factory control systems, the advice falls a bit flat.

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

Implementing the driver-less highway system. If for no other reason then to get rid of people driving cars, and thus implicitly, this book. 

(Sorry Don, but it's too wordy and repetitious for me)

XP Installed- Chapter 13-15

You mocked out the
launch code, right?

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Todays XP Installed reading chapters are "Unit Tests", "Test First, By Intention", and "Releasing Changes".

Chapter 13 is about unit tests. It starts by saying why they are useful: they're about like mini-acceptance tests; if I change something, I have some assurance that nothing broke if the tests pass. It then goes through a simple example, answering the question of "How do I unit test a module that depends on other incomplete modules", and then goes on to answer questions regarding testing. 

Chapter 14 walks through a (supposedly) actual TDD session between the authors of the book. In SmallTalk. In it they create a summary class, for what I assume is supposed to be some form of order/requisition summary. 

Chapter 15 talks about how changes are released from a developer work station to the wilds of /dev. Basically, once at a sufficient milestone, (hopefully at least daily), you go through and merge you changes with any more recent changes, and then commit to dev / the_trunk / svn / source_control / the_big_round_file_in_the_sky once all tests are back to passing at 500%. 

Discussion:

1. Why is this paper interesting or significant?

It briefly mentions some of the problems with TDD- testing the database tends to be finicky, and is better avoided in favor of using mocks and a limited set of direct to DB tests; threaded things are hard to test; automated testing of the GUI never ends well, etc. I think they could have generalized "testing the database" to "testing something with external effects"- if it goes outside the PC bounds, by network connection, USB, serial, or other, chances are there'll be problems. Even if it's all on the box, going outside the App Domain (file access; communicating with another process) can be finicky or nearly impossible to test). They also mention "don't test things which are obvious", which is nice, and one of the short comings in my previous experiences with TDD.

2. What are the faults of this work?

I apparently said it last time, but I'll say it again: TDD tends to have one of two effects on a code base. Either a massive glut of tests add to the momentum required to make any sort of non-trivial (non-additive) change to the code base, or the testing is so sparse that it doesn't really provide any guaranty that nothing broke. Or, even better, it'll do both. 

I'm in favor of testing those things that need to be tested. Those things that you look at and somewhere in the back of your head is the tiniest bit of self doubt. Where there is something worth testing. Too often I see unit tests akin to "Do I get an empty collection on construction", which just robs the usefulness of having tests to refer back to.

That, and SmallTalk? Srsly? You put a note at the top "You'll do fine", then spend a quarter of the chapter explaining the idiosyncrasies of SmallTalk in a planet dominated by the bastardized offspring of C? Srsly? 

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

In theory unit testing and proper handling of releasing to dev. In practice, half of my work is tied to the micro controller, a wonderful combination of C/C++ (typically unfriendly unit test frameworks), low memory availability, and low program space. The problems at this level are more likely to be a faulty hardware setup then faulty code. But, that's just my opinion.