The Mythical Man-Month Ch 7-9

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 7 discussed the Tower of Babel, linking it to how communication is pivotal to programming projects. Lack of communication and organization often causes large projects to fail. It is suggested that teams should communicate informally to interpret documents, though regular project meetings, and through a workbook. The project workbook is a structure that's imposed on all documents that are produced for the project, ensuring a formal structure and control of distribution. Each programmer should be allowed to see all information with timely updating.

Organization is used to reduce the amount of communication and coordination required, and often consists of a tree-like structure of authority and responsibility. To be effective, each sub-tree needs a mission, producer (assembles team, divides work, establishes the schedule, and communications outside of the team), technical director (conceives design and sketches internal structure), schedule, and interface definitions between the parts.

A tree-like organization of authority and responsibility. Source: support.novell.com

Chapter 8 discussed actual data regarding the estimating of tasks. Effort was described as a power of size and given a quantifiable equation. Finally, various data were discussed, including Portman's data (each job takes twice as long as expected), Aron's data regarding programmer productivity on large systems, Harr's data (productivity falls into two categories: control programs at about 600 words/man-year and language translators at about 2200 words/man-year), OS/360 data that confirmed Harr's data, and Corbato's data (data is comparable in terms of the kind of effort included). By looking at these various estimation data, two major conclusions were made: 1) productivity seems constant in terms of elementary statements, and 2) programming productivity may be increased by 5 times when a high-level language is used.

Finally, chapter 9 discussed how space, cost, size, and time factor into a programming project. Size control is very important, as unnecessary size can be bad. As for space, more function of the program results in more space, but function must be traded for size. This limits the range of functionality. Also, there are space-time trade-offs, whereby more space results in a faster program. Finally, the author emphasizes that representation of data or tables is a must, insisting that it will save time.


Discussion
These chapters brought up some very interesting ideas. For one, I agree that communication and organization are  necessary for a successful project, as many people have to be able to work together to meet a single goal: releasing a unified, working product on time. Therefore, constant communication should be maintained. The data of estimation that was discussed seemed rather dull and uninteresting, but the conclusions that the data led to seem like they could be put to good use. Even the trade-offs discussed in chapter 9 could be useful, so that programmers and designers can keep in mind what should be limited when designing a product

The Mythical Man-Month Ch 4-6

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 4 discussed aristocracy, democracy, and system design, and how those principles apply to development of a programming product. The idea of conceptual integrity was approached, insisting that only one set of design ideas be followed as opposed to a mesh of many ideas. However, it dictates that design must proceed from only a small set of minds, rather than a democracy. Pressures of schedule leaves programmers waiting while a small set of designers hurriedly put something together. It is suggested that the creative phases (architecture, implementation, and realization) can actually be done in parallel.

Chapter 5 discussed the Second-System Effect, otherwise known as a designer's tendency to put all of the flairs and features thought up while working on the first system into the second system he builds, making it a very bad design. Because of this, one should always be aware of the flaws of the second system, and be careful to not put too many unnecessary features into it.

A victim of the second-system effect.
Source: myninjaplease.com

Chapter 6 discussed communication, and how the manager ensures that everyone is kept up-to-date. To do this, there are written specifications, formal definitions, direct incorporation, and conferences that require all high-level personnel to meet and discuss problems and solutions. A telephone log is suggested for logging questions and answers, and product testing is recommended for checking the programs against specifications.


Discussion
These chapters brought up some very good points, including the need for communication and good design. I particularly liked the description of the second system effect, as I was unaware of it. It does make a lot of sense, though. I think that many of these suggestions should be applied to our current and future projects, such as continuous design, frequent communication and specifications, and being wary of the second system effect.

The Inmates are Running the Asylum Ch 3-5

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 3 discussed the problem of wasting money in software development, since it lacks of understanding of what it means to be "done". Management insists that shipping a product sooner rather than later is better due to lack of clear vision, and programmers race to meet the too-short deadline. Since it is easy to get carried away with adding more and more features, it is difficult to know when a piece of software should be considered done. This chapter described Parkinson's Law (work will expand to fill the time allotted to it), feature-list bargaining to define a precise list of features, prototyping, and the wrong idea of the unpredictable market.

Chapter 4 discussed the "dancing bear", or software that is sub-par, but acts as if it is not. Users won't know there's something better until they see real "dancing". The faults of software were then listed, including forgetfulness, laziness, and inflexibility.

A dancing bear. You won't know real quality until you see an actual dancer.
Source: theolivepress.es

Chapter 5 discussed how important it is for a product's success to have the fierce loyalty that a well-designed product generates from its clients. The primary qualities of a high-technology business include viability (the contribution of business people), capability (what technologies bring), and desirability (what makes the product something that people would want). To design a good product, first you should decide what customers will find desirable, then build it and sell it.


Discussion
I think these chapters brought up some very helpful hints about producing good software, although the dancing bear analogy was a little strange. I especially liked the statement that programmers don't know what done is. It's true, we often just keep saying "oh, I could add this feature!" It would be good to keep this in mind when working on the capstone project, and future programming projects, so that we can limit the number of features to only those really desired by the user.

Extreme Programming Installed Ch 22-24

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 22 discussed how to handle defects. The point that the authors made was to never call defects bugs, since they were put there by programmers. The idea is to make it easy to report problems, and to schedule corrections into the iteration, keeping in mind that these things take time. Most importantly, the prevention of defects was discussed, including determining where previous defects originated.

It's not a bug, it's a defect.
Source: allempires.com

Chapter 23 was a conclusion for the XP process, summarizing what every previous chapter discussed.

Chapter 24 discussed trying to reach an impossible deadline. Instead, the authors suggest creating a realistic deadline by knowing all the things that have to be done, having a solid feeling for each of them, and knowing how many real days it takes to get a perfect engineering day. Using user stories and project velocity, a realistic estimate can be created. They suggest that these real estimates should be told to management, and that programmers should stand up for themselves against managers.


Discussion
First of all, I found it interesting that we read the conclusion chapter, and almost half of the book is still left to go. Basically, these chapters said that defects are bad and that programmers are afraid to give real estimates to their managers. Both of these statements are fairly obvious, and didn't really need entire chapters to explain. In particular, the advice to keep insisting to managers that their estimates are wrong and that your very long-term estimates are the ones that should be followed seem like it could easily put you in a bad position, as in out of a job. However, the idea of handling defects and bugs as soon as they occur, and factoring them into the schedule seems like good advice that we should probably follow in the future.

The Inmates are Running the Asylum Ch 1-2

Reference Information
Title: The Inmates are Running the Asylum
Author: Alan Cooper
Publisher: Sams Publishing

Summary
Chapter 1 presented "riddles", such as "What do you get when you cross a computer with an airplane?" or "What do you get when you cross a computer with a car?". Each of the riddles was given the answer: a computer. The author gave examples for each of the situations, such as a computer-based navigational system within an airplane, and perils associated with bad design of such a system. The author also introduced the term "software apartheid", defining it as the situation where normal people are forbidden from entering the job market and participating in society due to the fact that they can't use computers effectively.

Computer + Plane = Computer
Source: www.visualphotos.com

Chapter 2 discussed cognitive friction, defined as the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes. Such problems occur with things such as metadata that occur in program design. Interaction design is compared with interface design (suggests only passing messages to users), behavioral design (how elements of software should act and communicate), and conceptual design (considering what's valuable to users). The chapter then discussed how designers and programmers tend to add more features because of the virtual lack of cost.


Discussion
From the title of this book, it sounded a bit more interesting that it actually is. But I did like how the author used the metaphor of inmates in a prison, comparing inmates with programmers. If inmates were in charge of their own prison, it would be disastrous; therefore, the author says that when programmers are in charge of their own projects, the results are also disastrous. These chapters were pretty interesting, but it just seems to be saying many of the same things that Donald Norman said over and over again in his design books that we've read. Maybe if this information had been new, it would have been more interesting. Once again, I think that some of the ideas suggested in these chapters could be easily and helpfully adapted to our capstone project, such as keeping in mind the fact that designing our project just for ourselves may not lead to the best product possible. It would be helpful for us to consult non-technical people, or even just non-computer science majors, to see how easy to use they think our program is. They could have some very helpful advice for us that we are currently unable to see due to our level of immersion in the project.

The Mythical Man-Month Ch 1-3

Reference Information
Title: The Mythical Man-Month
Author: Frederick P. Brooks
Publisher: Addison-Wesley

Summary
This reading mostly discussed programming practices by relating them to some fairly well-known concept.

Chapter 1 discussed the concept of a tar pit, relating large-system programming to it. This is justified by saying that the accumulation of many simultaneous, interacting factors in large-system programming increasingly slows the motion of its progress. The transition of program to programming product to programming system to to programming systems product was described. The author then presented both the joys and woes of programming, including its appeal to creativity and the dullness of debugging.

Chapter 2 discussed the Man-Month and just why it is mythical instead of true. The man-month is a trade-off between manpower and months, a unit of effort used for estimating and scheduling, leading one to believe that more man power leads to a shorter programming time. However, the author emphasizes that this is not true, due to sequential constraints. On the contrary, adding more people to a project can actually lengthen the amount of time to complete it, due to time needed for training and restructuring the development process for more team members. The author proposed a rule of thumb for project scheduling (1/3 planning, 1/6 coding, 1/4 component tests, 1/4 system tests of the completed project).

Chapter 3 proposed a new programming team structure, likening it to a surgical team. While smaller, smarter teams are generally preferred, they are impractical for large programming endeavors. However, for a team of 10 people, the surgical team setup is proposed, whereby there is one main programmer (i.e. the surgeon) that does the design and coding. He is supported by a team that consists of a copilot that shares in the design and coding, an administrator that handles managerial type things, an editor that transforms the surgeon's manuscripts into production documents, the clerk that's maintains technical records, two secretaries for helping project correspondence, a toolsmith for creating and maintaining helpful tools, a tester for devising test cases, and a language lawyer for finding unique, efficient ways to use the programming language for tricky things. For larger groups, it was proposed that this team should be enacted, just scaled up and with a coordinator between the main programmers.

An actual surgical team.

Discussion
This book seems to be pretty interesting so far. I like the discussions about programming practices, and the proposed solutions seem like they could be very helpful to keep in mind for managing large programming projects. I found the surgical team analogy to be a little strange, but it does make a kind of sense. I think that many of the suggested solutions to problems that the book discussed could be helpful to implement in future programming projects or even our current capstone project. The scheduling issues and team structure issues in particular seem like they could be very useful to apply.

Extreme Programming Installed Ch 19-21

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 19 discussed the idea of steering due to changing of changing priorities and estimates. The idea is to learn throughout the project, and adjust planning for the project accordingly. Adjustments should include reestimating similar stories to ones that are taking longer than planned, and rearranging and splitting stories to fit them into the time needed.

Chapter 20 discussed how to steer the iteration by tracking and improving estimates. Since the goal of an iteration is to complete stories, or to complete as many as possible within the time given, the team should track how the project is going, check progress against the estimates, and reallocate resources as needed to steer the project in the right direction. The purpose of steering is to get as many stories completed as possible, so to do this, a tracker is appointed to check every few days on the status of each story the programmers are working on. He identifies problem areas and gives the team a chance to deal with them. If the team cannot solve the problem, they go to the customer to solve it. This tracking gives the team the best chance to recover from a problem area.

Chapter 21 discussed how to steer the release by tracking what's done, how fast you're going, and how well the system works. At this level, you need to know when you're going to release and what you'll have done when you release. This is done by controlling the scope. By deciding what to do next and what to defer, by release time there can be a system that does what it needs to with the best features possible in the amount of time given.

A steering wheel, for steering. At least it applies more than the book's image of a steer.
Source: http://www.r32argent.ca/

Discussion
These chapters all seemed to be saying the same thing: Steer the project so it does what it needs to by the release time. Each chapter redefined steering, and presented some new ways to actually do it.The information probably could have been presented only once, but I did like the idea of tracking, as it seems like keeping track of progress so frequently would really help keep things under control. Especially since the chapter suggested ways to deal with problems discovered from tracking, recommending that the programmer present the issue to the team to be dealt with by everyone. I feel like it's a good way to solve the solution before ever having to alert the customer that there's something wrong. I think we should probably implement some sort of tracking system for our capstone project, as it would help us to stay on track from week to week and hopefully complete our production goals for the project.