The Inmates are Running the Asylum, Chapters 6-7

Reference Information
The Inmates Are Running the Asylum
Cooper, Alan
Sams Publishing, 2004


Summary
Chapter six, which shares the same title as the book, really introduces the main point of the entire work. The author states that the current poor usability of software systems is a direct result of the engineers being the interface designers instead of using interaction testing. Even the best specifications cannot make up for a lack of interaction testing. The system designer will always favor whatever is easier to implement, even at the expense of usability. The author says that you can "expect what you inspect", meaning that if the design team ignores the user interaction, the resulting software will be frustrating to use for the average user. Programmers are the typical interaction designers, and they build the interface that is suitable for them and others like them (power users). The difficulty that programmers have in designing both the software and the interaction is that these two aspects require to completely different viewpoints: that of the hardware and that of the user (human). The programmer is trained to focus on the mathematical and engineering side of software development, which is represented by hardware-level thinking. However, with the decline of computing costs, it is now more expensive to program for maximal efficiency while ignoring usability. The author actually recommends writing the program in as simple way possible so as to focus on usability and trusting to powerful modern computers to be able to handle its inefficiencies. The interface and back-end should not be thought of as two distinct parts of the project. He claims that the failure of engineering methods in solving these problems is proof that engineering methods cannot solve these problems.


Chapter seven, entitled Homo Logicus, emphasizes the differences in mentality between programmers and the average software user. Programmers trade simplicity for control and success for understanding. The author offers a simple "test", which he calls the Jetway Test: upon entering an airplane, a person has a choice of entering the cockpit or going into the cabin. The author claims that programmers would prefer to enter the cockpit (symbolizing control) and normal people would choose to sit in coach. Programmers like to have control over things that interest them, the more complex and deterministic the system, the better. The cost of this control is increased effort and complexity. Most people, however, seek simplicity and will trade control to achieve it. Programmers seek understanding, while most people look for success. The programmer designs the interface of the product to mimic its internal workings, which is perfectly reasonable from his point-of-view. Programmers also despise edge cases. The author claims that programmers become the jocks of the adult world because of their increased intelligence and arrogance.


Opinion
These two chapters lacked much useful material. The most interesting part was the difference in psychology between programmers and normal people. Obviously, many of these stereotypes apply to myself and many of my friends.

Programmers: different than normal people

Extreme Programming Installed, Chapters 25-27

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter 25, called How to Estimate Anything, primarily uses an example to explain how a large problem can be broken down into smaller parts, which are easier to estimate and implement. The work being done needs to be put in terms that the customer can understand so that they can maintain the direction of the project. The team must break up each large story into a number of smaller ones that focus more on implementation. These are what the programming team actually uses. 


Chapter 26, entitled Infrastructure, discusses why the programming team should only design and implement for the features that are currently at hand, and not those that could be in the future. On a typical project, the programmers waist considerable time at the beginning writing infrastructure. The author suggests that this is waisted effort. The goal is to deliver business value, which is best accomplished by working on the problem at hand and not for potential future problems. Any absolutely necessary infrastructure work should be tied in to an existing story. If a story cannot be found that is suitable, the infrastructure probably is not necessary. Coding should focus on simplicity and be refactored out later if changes are needed.


Chapter 27 simply describes an example where someone took the blame for every problem, even though everyone know it was not actually his fault. 


Opinion
There is too little material to actually form an opinion. All of this material is rehashed anyway, except for the Chet example, which was ridiculous.

The Mythical Man-Month, Chapters 4-6

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
Chapter four, entitled Aristocracy, Democracy, and System Design, discusses the need for putting as few people in charge of designing the architecture of a software project as possible. The author states that conceptual integrity is the most important consideration in system design. It is better to have fewer features if the system would achieve a more focused design. The primary objective of tools is to increase ease of use, which is only enhanced when the time gained in functional specification exceeds the time lost in learning. The ratio between these two is the real test of system design. No matter how much functionality is provided, a system must be as simple and straightforward as possible. To maintain conceptual integrity, the design of the system must be produced by as few people as possible. Architecture design and implementation should not be shared by the same person. 


Chapter five, called The Second-System Effect, introduces the notion that a designer's second system will actually be more susceptible to mistake than his first. This is because the designer tries to apply too much of what he learned during his first attempt without due consideration. His later designs will be much better after the many mistakes of the second. The author supports the idea of a throw-away implementation - analogous to a prototype. The architect needs to be extremely disciplined on his second creation to ensure that it is not dangerously filled with superfluous features. 


Chapter six talks about the need for communication and documentation. A manual is the external documentation for the tool, which the end user will use. It must describe everything the user sees, but it should not explain implementation details or anything the user does not see. Formal definitions could also be used, but the author suggests that these are too unwieldy to be practical. The only formal definition with any value is the program code itself, which is the best and most accurate definition. The author recommends having two sets of meetings: a weekly one between all the system architects, and one with architects, implementors, and businessmen. 




Opinion
The only thing of note is that it is better to have fewer designers since that leads to a cleaner and more straightforward design. I have noticed similar patterns in my own groups: if more than one person is crucial to the design, it will most likely not be very clean.

The Inmates are Running the Asylum, Chapters 3-5

Reference Information
The Inmates Are Running the Asylum
Cooper, Alan
Sams Publishing, 2004


Summary
Chapter three is about how companies waste time and money on rushed and poorly implemented software projects. A key idea is how managers and programmers view project completion. One of the primary driving forces in software development is time to market: being the first to get a product out there can generate enormous success. Therefore, management wants to get the product coded as fast as possible without real regard to quality and usability. The author suggests that shipping a product late does not seriously dampen the chances of success for the product. Contrary to popular opinion, having a large feature set should not be the primary goal. Many times, these features simply get in the way. The objective, therefore, is to provide the best usability, even at the cost of features. The author believes that prototypes should be created for each product, then completely thrown away. The experience gained from this is invaluable and helps make the final product much better.


Chapter four, entitled The Dancing Bear, discusses the failure of software in regards to the typical user (i.e. not power user) who is frustrated by needlessly overcomplicated software. These users just assume that all the problems must be with themselves since, if it was a real problem, then it would have been solved by now. Many times, users a blinded by the superfluous features and do not see what poor interaction the software is actually providing. The chapter is concluded with a list of what the author thinks is wrong with current software:

• software forgets most of what you do or prefer
• software does not work hard enough for the users
• it is stingy with information
• the user is forced to operate on the software's level
• it blames the user for any mistakes

Chapter five is about the fickle nature of the consumer, and how poorly designed products will be abandoned in favor of easier to use ones without regard for manufacturer. The chapter outlines a model consisting of three factors that determine whether a product will be a commercial success. These factors are: capability, viability, and desirability. Capability is simply whether the product can be made. Viability is whether the product can actually sell. Desirability is delivering what the users really want. If all of these are achieved, the product will engender strong customer loyalty. 

Opinion
There was some interesting material here. My best observation is when the author is talking about the failure of email in chapter four, he discusses the lack of threaded conversations in email clients at the time of writing. It is somewhat interesting that since that time Gmail has appeared and gone on to such great success.

Extreme Programming Installed, Chapters 22-24

Reference Information
Extreme Programming Installed
Jeffries, et al
Addison-Wesley Professional, 2000


Summary
Chapter 22 is entitled Handling Defects. Firstly, defects should never be called bugs. Defects reduce the business value of the software and also take away future value because time must be spent in correcting them. Defect correction should use a similar scheduling system as the extreme programming already uses: note cards. The customer (or reporter, as it were) would simply write the issue on a card and schedule its completion for an upcoming iteration. More urgent fixes may need to push other jobs out of the current iteration so that they can be completed in time for the next release. If many issues arise, programmers could be assigned to handle incoming reports on a rolling basis. The presence of a bug in released code indicates that there is an issue with both the unit and acceptance tests; this must be rectified to ensure that further bugs do not slip through. Bugs typically manifest at the edge of what is being tested - just outside what is expected. Many times bugs will cluster around a particular system, which means this system needs extensive checking or even reshuffling of the programming team.


Chapters 23 concludes the main portion of the book and lists many of the topics that were discussed in detail earlier. Extreme programming allows the programming team to better communicate with each other, the customers, and managers. The core values of extreme programming are simplicity, communication, feedback, and courage. The topics that the conclusion deems important are:

• On-site customer
• Small releases
• Planning
• Metaphor
• Simple design
• Pair programming
• Collective code ownership
• Continuous integration
• Coding standard
• Testing
• Refactoring
• Forty-Hour Week

Chapter 24 discusses ways to estimate the time of completion and how to bargain with customers and management to ensure that maximum value is delivered in a timely manner without overloading the programming team. Time should be estimated in perfect engineering days, which is the amount of work a programmer could get done if he had a full day to work without interruptions. The authors recommend planning to take three times longer than what would be accomplished in perfect engineering terms. All the stories are analyzed and assigned a cost that corresponds to this estimated work effort. The team needs to keep the customer and management up-to-date on progress and the expected delivery date, which changes based on velocity. 

Opinion

There is nothing really new presented in these three chapters. The only thing of note is the stipulation that it may be necessary to assign people full-time to handling incoming bug reports. If it got to that point, the team must not have been following extreme programming very well or the product is very poor.

The Inmates Are Running the Asylum, Chapters 1-2

Reference Information
The Inmates Are Running the Asylum
Cooper, Alan
Sams Publishing, 2004


Summary
The first two chapters of The Inmates Are Running the Asylum are part of a section called Computer Obliteracy. This section discusses how computers have found their way into every device imaginable and how utterly frustrating these devices become to anyone who is not a computer power user.


Chapter one, entitled Riddles for the Information Age, introduces many examples of problems caused by the integration of computers, or even more importantly, software, to many machines and devices. Those examined include an airplane, a camera, an alarm clock, a car, a bank, and a warship. The author emphasizes that computers may be very precise while still being very wrong. Some attribute this to human error, but the author believes that the machine should have been able to detect when something just did not seem "right". As devices morph from mechanical means to computer-powered machines, they begin to act more and more like a computer and less operate less intuitively. Computers, as a result of poor programming, fail to interact adequately with humans and constantly punish its users for every transgression. This leads to a splitting of the workforce: those who can handle the exacting nature of the modern computer, and those who cannot. The author terms this a "software apartheid". This is a result of the difficulty in use of software as it exists currently. The programmers and system designers need to be trained to make software with an emphasis on usability. The interface should be completely designed before programming so that improvements can be made as testing and development are taking place.


The idea of cognitive friction is the main theme of the second chapter. Cognitive friction is "the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes." Current software-based devices do not have a one-to-one correspondence to the user's manipulation. To help alleviate this, products need to be designed by interaction designers instead of software engineers. The author says that there are two forms of design: the user-facing side, and the rest of the system. Software engineers are poor at designing adequate interfaces because they typically do not use the products that they produce and their design decisions are often based on what is easiest for them to implement. The author prefers calling interface design "interaction design" since interface design has other connotations than natural communication. Behavioral design determines how the software should act and communicate. Conceptual design considers what is actually valuable to the end user. Designers need to think conceptually, then behaviorally, then finally about the interface. The main goal of design is to not make the user feel stupid or inadequate. Cognitive friction is not inherent to technology, it is made to exists by those who create the technology. Since software can be so easily created (compared to physical machines), much software becomes bloated and difficult to use because of the excess of features. Cognitive friction forces people into two groups: apologists and survivors. Apologists are those who were able to overcome the difficulties and felt empowerment therein. The author also shows a "Euphemism Pyramid". This pyramid has power users at the top, computer literate users in the middle, and naive users at the bottom. He claims that this is the sort of thing companies look at when designing products, but they end up discounting the naive users in favor of the computer literate and power users.


Opinion
These two chapters had an obscene amount of material. The only interesting part of the two chapters is something that I had never considered: what an average, or naive, user would expect something to do. His point that all of the engineers are surrounded by others like them clouds their vision to what the average user's abilities and expectations. Some of his examples are quite absurd and out of date. Many of his complaints seem to have been addressed by developments since the book was released. His idea that there would be a schism between technical and non-technical users' ability to find work in the modern age has already taken place. However, this situation is resolved naturally as those without the skills are retiring while younger people with much more experience with computers enter the workforce.

The power user sees and understands

The Mythical Man-Month, Chapters 1-3

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
The first three chapters introduce the key concept of the book and a potential team structure that would be best suited for team projects. The first chapter, entitled The Tar Pit, explains the difference between a program and a finished programming systems project. According to the author, there are four different types of programs. A basic program simply accomplishes a specific task. A programming product must be generalized, have extensive testing, and be thoroughly documented. A programming system consists of many programs or systems acting in unison. A programming systems product is a merger of the previous two types. The author associates a cost to each of these: base effort for program, 3x effort for both product and system, and 9x the effort for a systems product. Next, the pros and cons of programming are listed to emphasize the joy and work that programming brings.


Chapter 2, which has the same title as the book, frames the problem that is often faced in software projects and attempts to explain why throwing more people at project does not help it finish earlier. The author lists these as the reason why software projects fail:

• Estimations are typically poor
• Effort does not equal progress
• Since there is little confidence in the estimates, assertiveness is lacking
• Progress is poorly monitored
• When things fall behind, the typical solution is to add more manpower

In addition, the author claims that cost is a function of men and machines committed to a project, but progress is not. Men and month costs are only equivalent if the tasks are highly parallel with little communication between the individuals. Communication itself should be added to the work done. Communication also encompasses training, which is the main hurdle to adding new people to a project since it takes productive people away from their work while they instruct. The author recommends a schedule of:

• 1/3 planning
• 1/6 coding
• 1/4 component and early system testing
• 1/4 system testing

The chapter is concluded with the idea that adding new programmers to a late project costs the project time and ultimately makes the project even later.

Chapter 3 introduces a team structure that was proposed by Harlan Mills. The team is made up of these specialists:

• The surgeon
• The copilot
• The administrator
• The editor
• Secretaries
• The program clerk
• The toolsmith
• The tester
• The language lawyer

Opinion

Chapter 2 in particular presented some interesting concepts which hopefully will be expanded upon later in the book. The team proposed in Chapter 3 seems quite ludicrous, almost like a super heroes gathering. The team is so large and unwieldy, with so much support staff and so few actual "front-line" people, that it would be surprising if any work actually got done. It also seems like a complete waist of resources since these specialists certainly would not come cheap. Also, the ideas presented here completely contradict those from extreme programming.

Specialists, Assemble!