The Mythical Man-Month, Chapters 18-19

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


Summary
Chapter eighteen serves as a summary of the key points of all the previous chapters. For the sake of brevity, this chapter will be ignored since it was all covered before.


Chapter nineteen presents the author's views on the effect of The Mythical Man Month on software development (and in other fields as well), how its concepts have held up, discussion on the changes that have affected the industry, and the future. The author states that the book's success in multiple fields can be attributed to the fact that the concepts apply to any team-like organization. 


Conceptual integrity is the most critical facet of any product. The best way to maximize conceptual integrity is to have as few people design the software as possible. These people are called architects. The architecture, or design, of the system should be separate from its implementation. Therefore, the master architect should partition the overall system into smaller self-contained subsystems.


Off-the-shelf applications have started to replace custom implementations in many situations. These programs are prone to suffer from featuritis, where insignificant features make using the software harder or less enjoyable. To help overcome this, it is helpful to define the expected user, especially in these areas: who they are, what they need, what they think they need, and what they want. These can even be guesses, but they must be as detailed and explicit as possible.


The author discusses the explosive success of the Windows, Icons, Menus, and Pointing interface (WIMP) model for computing. He says that the WIMP model exhibits excellent conceptual integrity. There are some limitations to the interface: the author presents the problem of using two mice simultaneously and other annoying aspects. He expects the WIMP interface to be phased out within a "generation".


The author admits that his previous assertion that using the Waterfall Model in conjunction with throwing the first attempt out is completely wrong. Instead, he now believes that an incremental build model is better. First, a skeleton system should be created, with all of the functions existent but doing nothing. With this in place, testing can be accomplished from the very beginning of the project. Afterwards, the function stubs can be filled out with working code while being tested constantly. At every stage of development, the system should be running without error - even if it does not do anything useful. In addition, the author advises that the engineers should design the product as a family of related projects instead of one large project. The author also agrees with a certain critic that it is better to practice information hiding than to expose all of the internals to every programmer. 


Some data that had been generated since the publication of the book in support of the mythical man-month concept is presented. It concludes that adding more people to a late project does not necessarily make the project later, but does make it more costly. The quality of the programming team is by far the most significant variable for determining the chances of success for a project.


A more decentralized organizational structure is recommended because the increased freedom allows the programmers to be more creative an enthusiastic - much like small startup companies. The true advantage to this, from the managerial point of view, is that their power actually increases as they allow the programming teams more license.


The author says that the biggest surprise development was the sheer number of computers that are now available. The average American can now afford to own a personal computer, along with a vast array of software. All of this would have been inconceivable at the time of the original publication. This revolution has fixed many of the accidental problems with the software development process. Now, software can be developed and sold at a large scale, which minimizes costs. 


Lastly, the author discusses shrink-wrapped software. Using components that have been thoroughly tested decreases development time and effort. Metaprogramming is also introduced as a most favorable feature for a wide range of software.


Opinion
These chapters acted mostly as a summary or recap. The author admitting that some of what he advocated in the original book was incorrect added nice variety to the last chapter. It was nice to see that the modern incremental build system was presented as the recommended paradigm,

Incremental building

The Mythical Man-Month, Chapters 16-17

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


Summary
Chapter sixteen postulates that there is no innovation on the horizon that will fix the core problems of software development, which the author terms a silver bullet. The author advises developers to purchase already constructed components on the market, to use rapid prototyping, to grow software instead of building it, and making use of interactive and conceptual designers. Software encompasses properties that are either essential or accidental. Complexity is an essential characteristic of software - it will always be so. Accidents are difficulties that exist now but could be rectified in the future. The author believes that the hard part of creating software is the design, specification, and testing of the conceptual construct, not the implementation. Much complexity is created by pre-existing interfaces, which cannot be fixed by redesigning the software. The software itself is under constant pressure to change. Useful software is updated constantly to fix problems and add features. Another difficulty is that software lacks true substance - it cannot be visualized. The author says that this fact deprives the human mind of a powerful mechanism to reason about the structure. Breakthroughs made in the past had solved some of the accidental difficulties of software; the author lists:

• High-level languages - the most powerful advance; increased productivity, reliability, and simplicity
• Time-sharing - increased productivity and quality of product
• Unified programming environments - providing fixed interfaces, libraries, file formats; Unix, etc.

Next, the author lists some potential silver bullets:

• Ada - encourages modern program design, but the author thinks it will not have much effect
• Object-oriented programming - the author believes this holds great promise
• Artificial Intelligence - the author does not think that this will make much improvement
• Expert systems - inference engine based on rules garnered from experience. The author thinks it will be helpful for novice programmers 
• Automatic programming - creation of a program from its specification; unlikely to be successful
• Graphical programming - create program visually; software is difficult to visualize, however
• Program verification - can be done, but will only verify that it meets specification, not that it is right
• Environments and tools - better tools would enable better productivity
• Workstations

Lastly, the author lists some methods by which the essential difficulties of software engineering can be lessened:

• Buy versus build - purchasing pre-made components instead of building them
• Requirements refinement and rapid prototyping - allow the program to change as the needs change
• Incremental development - growing the program instead of building it. It is too hard to accurately specify a program before building it. The system should always work, even if it does nothing useful. This method enforces top-down design.
• Great designers - good designs come from good practices, great designs come from great designers

Chapter seventeen serves as a rebuttal to criticism for the previous chapter. It mostly comments upon additional studies done in the field and defends the positions presented before.

Opinion

Most of the objects from his silver bullets list have had substantial improvements since the publishing of the book. More interestingly, three out of four of the remedies for the essential software development process have become recommended practice in the field. Great designers, on the other hand, is very subjective and is very hard to determine if improvement has been made in this area.

The Mythical Man-Month, Chapters 13-15

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


Summary
Chapter thirteen discusses how programs should be designed and built, along with using milestones to measure progress and completeness. The most common bug arises from misunderstandings between authors of different components. The outward-facing functions and definitions of each component should be meticulously documented. To ensure quality, the fully-formed specification should be looked-over by outside experts. The author emphasizes the need for top-down design. Top-down design is a processes whereby a broad task definition is made and then subsequently refined in many steps that each focus on a smaller and smaller portion of the design. The author believes that this system was one of the most important advances in software engineering. Structured programming is important for creating program flows that are easy to follow, including removing most of the uses for GOTO statements. Interactive debugging, which is provided by most modern languages, enables the developers to find and fix problems rapidly. Plenty of code should be written for testing the system, which the author terms scaffolding. Each component of the system should be tightly controlled by one person who must approve any changes. Along with this, only one component should be added to the system at a time.


Chapter fourteen, entitled Hatching a Catastrophe, discusses milestones. Milestones are a result of having a schedule. They must be concrete and very specific. Milestones can indicate a transition between the phases of planning, coding, and debugging. Each slip of the schedule must be treated as a serious incident. The author recommends using a PERT chart to maintain the schedule. A PERT chart is created by creating three estimates for each event and combining them with three probabilities of reaching completion dates. Simply preparing the PERT chart gives a large benefit to the project.


Chapter fifteen, The Other Face, introduces various techniques for documenting code. A program is communicating both with a machine and also with other people. Therefore, it must be documented in plain language for them to better understand. Various things that need to be documented are purpose, environment, domain and range, functions/algorithms, I/O formats, operating instructions, options, running time, and accuracy and checking. Programs must be supplied with test cases so that the user can be sure that it is functioning properly. For future modification of the program, a flow chart should be provided that explains how the program works. However, the flow chart should only be a high-level overview, too much detail only interferes with understanding. The author recommends using self-documenting code where possible. This includes moving all documentation into the code files themselves. The variable names and formatting of the code can help as much as additional documentation.


Opinion
Most of what was presented has entered into mainstream programming thought since the book was published. We were taught about self-documenting code in our courses in school. The top-level design process appears to be the most natural way to attack large programs, so that they can be broken down into more manageable chunks.

An example PERT chart

The Mythical Man-Month, Chapters 10-12

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


Summary
Chapter ten, entitled The Documentary Hypothesis, discusses the need for extensive documentation during the development process. Documents that should be generated include the objectives, specifications, schedule, budget, organization chart, space allocations, and estimate prices. These documents collectively answer the questions what, when, how much, where, and who. Writing these documents will help expose inconsistencies in the product. In addition, the documentation facilitates communication and provides a convenient checklist of features. 


Chapter eleven is about the need to write a prototype system whose function is to expose most of the implementation issues that could not be foreseen. The author likens this to how chemical engineers must design and build a smaller pilot plant before building the real thing as a proof of concept. The first system build is rarely usable as a product. Therefore, management must plan to build the product twice, if it wants to deliver a remotely decent product. Another problem that frequently occurs is that the requirements for the software change during the development process. To counteract this, the software should be very modular so that any required changes only affect a small portion of the project. The whole organization must also be able to be flexible and to withstand change. The author gives examples of some companies abolishing all job titles: without a title, everyone has equal responsibility. Change continues even after the delivery of the "final" software. The cost of maintaining software can easily be 40% more than the cost of actually developing it. Since many of the people who maintain the software were not on the original programming team, many additional bugs may be introduced in the maintenance phase. Each defect that is fixed has a large chance of introducing another such defect. Even worse, constant fixing-up and patching will destroy the structure of the original program.


Chapter twelve discusses the need to use tools appropriate for the job. Most tools should be shared by the entire team. If each person on the team uses different tools, it dampers communication and efficiency. Common tools need to be found or created that satisfy the entire team. The author discusses many considerations that were relevant a very long time ago, but are omitted here. He says that it is far better to create too much documentation than to not fully document the software. Using a high-level language is crucial, along with interactive programming.


Opinion
Writing a prototype system and then throwing it away seems like an enormous waist of time, except that I have personal experience in this matter and can say that he is absolutely right. Many times, the first implementation uncovers many design flaws and pushes the software in a new direction.

The Inmates Are Running the Asylum, Chapters 8-9

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


Summary
Chapter eight discusses how an elitist culture has formed around software engineers and the negative effect that this culture has on the end-users. Engineers value program efficiency over the needs of the user. Programmers also like to reuse code that was already written to save effort. Sometimes this code is of questionable quality and is merely copied over and over again by many people because it was already written. This illustrates the conflict between what the programmer wants (ease of implementation), and what the user wants (ease of use). There is a reverence in the industry for technical skill. Therefore, the most talented and experienced programmers are exempted from helpful duties such as answering customers' questions. This actually insulates them from understanding what the customer really wants. The author believes that the mindset that is so prevalent throughout the industry of the need to preserve resources (what he calls scarcity thinking) hampers the improvement of interaction design by keeping the focus on technical details.


Chapter nine, entitled Designing for Pleasure, introduces the concept of personas. A persona is a precise description of a user and what he would want to accomplish. Simply asking the real user typically yields poor results; the user does not really understand the problem. The users that are used for designing the software are entirely fictional. In fact, it is far better to design for only one of these personas. Having a small percentage of the total market absolutely love your product will guarantee success, as was discussed in an earlier chapter. In this way, designing for one user is actually the best way to design for the population at large. The more specific the persona, the better the results will be. Giving each persona a name is one of the most important parts since it begins to build the character of the user. Counter-intuitively, it is more important that the persona to be specific than to be the most accurate depiction of an actual user. Having personas allows the team to openly discuss the various skill levels of the users - this helps avoid writing the product for super-users. They also allow for easy determination of required features; programmers all-to-often want to make the software too general. The persona should not target the buyer since it is the actual user that matters. The author recommends creating between three and twelve personas per each project. However, only one of these will be the "primary persona". This is the user whose needs trump those of all of the others. This persona must be absolutely satisfied with the end product.


Opinion
Chapter nine was quite fascinating, apart for the ridiculously long example. The idea of personas - and that the software should be designed for only one user - seemed enormously useful. This is something that I would like to apply to my own projects.

I don't know what this is, but it says Persona, and that's relevant

Extreme Programming Installed, Chapters 28-30

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


Summary
Chapter twenty-eight, called Balancing Hopes and Fears, gives an example from the author's past. His team had decided to retain certain legacy reporting procedures from some software that was being replaced to help with a faster transition. The team did not understand much of the older system, even the parts that they were hanging on to. This fact is not documented on any charts, and was hanging over the team's heads as they approached delivery. However, the team decided to come together and discuss the problem so that the team could be more confident in themselves. The situation arose because there was a large portion of the code which had no acceptance tests since they were legacy.


Chapter twenty-nine, entitled Testing Improves Code, presents a very short example from Rich Garzaniti. The premise is that Rich had to refactor some troublesome code. Upon writing the tests, he discovered that a method needed to be modified and moved some code into a helper function. This change made the code simpler and more easy to understand. The author says that code that cannot be easily tested is typically not refactored properly. He also says that writing tests first will ensure that these situations do not arise frequently.


Chapter thirty presents an example from using extreme programming with Java. A corporate database system was being replaced by a newer one and the author's team was responsible for writing the replacement. The project used Javascript and LDAP. At first, each code change required up to ten minutes before its results could be seen. In addition, the poor setup led to many files being corrupted. The author downloaded a debugger and started writing test cases and was able to get the system straightened out relatively easily. By using testing and refactoring he was able to fix the system and also make future changes that much easier.


Opinion
There is no relevant material to evoke any sort of interest or opinion. The examples are very simple, yet dense, and do not offer anything that was not already presented earlier in the book.

The Mythical Man-Month, Chapters 7-9

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


Summary
Chapter 7, with its title asking Why Did the Tower of Babel Fall?, discusses the importance of documentation, communication, and organization. Teams communicate informally, meetings, and through workbooks. A project workbook is extremely important: it answers what, why, and the mechanics of the project. Communication is critical with the advent of the division of labor and specialization. Each person knows what only small parts of the whole project are doing and needs to communicate with others for the other parts. The author gives various situations that can occur between the producer and technical director.


Chapter eight, entitled Calling the Shot, talks about estimations and their inaccuracies. Coding should only be budgeted for about one-sixth of the development time of a project. The estimated development time for small projects cannot be interpolated to anticipated the cost of large systems. Testing showed that many programmers were underestimating the time to accomplish tasks by almost half since they did not consider that they would have many other obligations as well. Data supporting these conclusions from Aron, Harr, the O/S 360 project, and Corbato was presented. It is also asserted that using a suitable high-level language can increase productivity by as much as five times.


Chapter nine is called Ten Pounds in a Five-Pound Sack. The chapter discusses space complexity and planning. The design team must set targets for the space allowed for each component of the system. Controlling size involves studying the users and what applications they use. In addition, each component needs to have a set access budget (for things like the hard drive). To help estimate, what each component does needs to be well-specified beforehand or the estimation will be very inaccurate. However, using more space can increase performance of the system. Much improvement can be made by redoing the data representation format.


Opinion
Most of these chapters are highly out-of-date (it talks about typewriters...). Very little can be gleaned from its pages other than intellectual curiosity at the state of the industry thirty years ago. Most of what is expounded here goes against modern advise such as Agile development.

 This book is out-of-date

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!