The Mythical Man-Month Ch. 7-9

The Mythical Man-Month
Ch. 7-9
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

Chapter 7 focuses on the need for communication while working on team projects. The author first discusses the Tower of Babel as an example of when communication, rather than time and resources led to the failure of a project. Teams are often comprised of several  people working in different specialized roles. This differentiation makes communication important because the team needs to understand the status of the project as a whole and how they are going to combine their individual parts. The author suggests using meetings and workbooks to achieve this communication. The author especially stresses the use of a workbook because it gives the most detailed documentation of a project.

Chapter 8 discusses the need for correctly planning and budgeting projects. According to the author, only a sixth of the total development time should be spent on coding. This is due to the fact that many inaccuracies and bugs will need to be fixed before the final release of the project. Multiple projects being developed concurrently can also cause a hue increase i development time.

Chapter 9 discusses the importance of correctly budgeting the system requirements of components. The system requirements, such as hard drive space requirements should be determined by analyzing the systems of the users. The system should be designed with the space-speed complexity trade off in mind. That is, in most cases the more space a system takes the faster it will run. The system designer should design the components of the system to not exceed the space limitations of the users and at the same time not make the system so slow that it is unusable.

Discussion:

This reading is interesting because it discusses several trade offs that system designers should consider when designing a software system. I do think that several of the points made were common sense for the audience of the book. This work can be applied to anyone who is designing a software system or is going to be managing the development of a software system.

Extreme programming installed Ch. 22-24

Extreme programming installed
Chapters 22-24
Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?

Summary:


Chapter 22 focuses on defects. The authors describe defects in a similar way to user stories. For instance, defects should be written onto note cards and given to the person most appropriate to fix them. Defects are also scheduled to be fixed in iterations and can be prioritized based on importance or the length of time it will take to fix the defect. If any defects manage to get through unit and acceptance tests then those tests need to be fixed in order to prevent new defects from being added to the code base.


Chapter 23 is very brief and discusses the values of extreme programming. These values include communication, feedback, and courage. The authors conclude the book by offering recommendations and discussing practices that reiterate ideas discussed in earlier chapters.


Chapter 24 discusses the aspects of planning and user story estimation. During the planning phase the authors suggest estimating time to be 3 times as long as it would take if the programming team were to work the entire day uninterrupted. The authors also discuss the need for open communication between the programming team and the management. The team should be able to give practical estimates of user story completion times to the management without being pressured into giving lower times than they can produce. This aspect is important in scheduling a plan that will be practical to complete without overloading the programming team.


Discussion:

This reading is interesting because it goes into detail about how to find and eliminate defects. I have never used a note card system for tracking bugs but I think that having something physically in your possession to indicate the need for you to fix a bug would be useful. Aside from the bug tracking chapter this reading felt like a repeat of previous chapters with very little extra information. This reading can mostly be applies to management that want to schedule a software project or want to include defect fixing into their schedule.

The Mythical Man-Month Ch. 4-6

The Mythical Man-Month

Ch. 4-6
Brooks, Frederick P
Addison-Wesley, 1995

 

Summary:

In chapter 4 the author discusses the importance of system design. According to the author, the design of a system's architecture is one of the most important aspects of a software project. As a result, the architecture of a system should be designed by as few people as possible. The author also discusses the importance of usability in the system's design. According to the author it is more important to achieve a more usable system rather than a system that has a large amount of features but is difficult to use. The author also suggests that the design of a system and the implementation of a system be handled by at least two different people.

In chapter 5 the author discusses second systems. According to the author, a designer's second system is more at risk of mistakes than his first due to the fact that the designer will take the knowledge gained from his first attempt and immediately apply it to the second attempt. This can cause the designer to not put enough time and effort into the design. To remedy this the author suggests that designers create a throw-away implementation before designing the actual system. This will allow the designer to spot flaws in his design and will hopefully cause him to be more careful on his next attempt.

Chapter 6 focuses mostly on documentation for software projects. The manual is the documentation that the end user will be seeing. The manual should provide a reference to everything that the user can interact with but should not go into implementation details or anything behind the scenes. The author suggests that the code of the software is the best definition of the software but is not a practical means of documentation.

Discussion:

This reading is interesting because it discuses the importance of system design to the overall success of a project. However, I think that having different people or parties designing and implementing the system can be just as troublesome as having the same person design and implement the system. Personal conflicts or poor communication can cause projects to fail when different parties design and implement the software. This work can be applied to designers who are beginning to design a software system.

The Inmates Are Running the Asylum Ch. 3-5

The Inmates Are Running the Asylum

Ch. 3-5
Cooper, Alan
Sams Publishing, 2004

The third chapter focuses on the disadvantages of rushing a software product out to market. The author suggests that managers tend to focus more on rushing products out to market so that the product will have a quicker time to market and will be more successful. Often time this comes at the expense of features and usability. The author believes that product development should focus the most on usability and focus less on the number of features and time to market.

Chapter four discusses how poor usability can cause software to fail when used by non power users. When software is overly complicated it can be hard for inexperienced users to navigate to the features that they actually want to use. This can cause the user to get frustrated or even feel that they are at fault for not being able to operate the software when the poor interaction is really just a result of poor design. 

Chapter 5 gives a brief discussion of a model for successful software products. The model consists of the components of capability, viability, and desirability. Capability is the factor that determines whether or not the software product is able to be made, viability is the measure of whether or not the product will be able to sell, and desirability is the ability of the software product to deliver features that customers want.

Discussion:

This reading is significant because it discusses many aspects of software development that are often overlooked. For instance, the model of success discusses in chapter 5 provides discusses the factors that make for the commercial success of a product rather than the technical success. The only faults I found with this reading is that the author seems to discuss software that is intended for a broad audience and does not discuss custom software or software targeted at technical professionals. This work can be used by anyone who is going into the business of selling software or developing software to be sold.

The Inmates Are Running the Asylum Ch. 1-2

The Inmates Are Running the Asylum

Ch. 1-2
Cooper, Alan
Sams Publishing, 2004

Summary:

The author begins the reading by discussing the problems that computers can cause when they are integrated into a large range of devices. The root of this problem is that machines that integrate with computers are becoming more and more like computers and less like machines. This is a problem because their operation is becoming less intuitive and less obvious to non computer power users. These non power users are often frustrated with their inability to communicate effectively with these machines and feel as though their are being punished for their lack of knowledge. Software designers need to take this into account and design systems intuitively to allow non power users to use them effectively as well. Failure to do so will further increase software apartheid, where workplaces are separated between those people who can interact with certain software and those who cannot.

The author continues the next chapter by discussing cognitive friction and its importance to computer human interaction. Cognitive friction is described by the author as "the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes." Cognitive friction in interfaces can be attributed to the fact that user interfaces are often written by software engineers instead of interface designers. Software engineers will often choose to design the interface based on what is easiest to implement rather than what is best for the user. Instead, interfaces should be designed based on how the end user interacts with the program. 

Discussion:

This reading is interesting because it describes the plight of the non power user. As a power user it is often hard for me to understand how people can struggle with what I believe are very intuitive interface designs. The major flaw that I found with this reading was its wordiness. The two chapters consisted of several pages and could have been condensed very easily. This reading can be extended to software engineers that want to design user interfaces.

The Mythical Man Month Ch. 1-3

The Mythical Man-Month

Ch. 1-3
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

The first chapter discusses the differences between types of programming projects. The first type of project, a basic program, only accomplishes a specific task. The next type, a programming product, is intended for a more general audience. Programming products are typically better documented and more throughly tested than basic programs. The third type, a programming system, consists of several programs or systems that work together to accomplish a task. The fourth type, a programming systems product, is a combination of a programming system and a programming product. A programming product or programming system will likely cost 3 times as much as a basic program, while a programming systems product will likely cost nine times as much.

The second chapter discusses why throwing more people at a project does not help it progress faster. Communication and training are the main hurdles that prevent progress from being improved by the addition of more team members. Adding more team members can often increase the time that it takes to communicate ideas inside the programming team. In addition, training new team members prevents the trainer from accomplishing the work that he could have been doing had he not been training the new employee. Due to these factors, adding a new employee to the programming team can cause the project to release even later than it would have if the team member had not been added.

Chapter 3 describes a surgical team and draws comparisons between surgical teams and an ideal software engineering team. The surgical team consisting of the surgeon, the copilot, the administrator, the editor, secretaries, the program clerk, the toolsmith, the tester, and the language lawyer. In this team, each team member, or type of team member, has a specific role to play and has specialized skills that help them perform that role. This is contrasted with the less ideal hog butchering team, where all team members play the same role and have the same skill set.

Discussion:

This reading was very interesting because it describes several mistakes that software managers make when staffing for a project. The concept of the surgical team, where team members have specific roles and work in unison is also an interesting concept and it would be great if more teams were structured this way. However, since the surgical team if full of specialists, it would probably be a very expensive team to staff and train. This reading can be extended to software managers that are tasked with hiring staff for a software project.

Extreme Programming Installed Ch. 19-21

Extreme programming installed
Chapters 19-21
Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?

Summary:
The main topic covered in this reading is the ability for a team to be able to react to unforeseen complications in a project, such as delays or design issues. This concept, also known as steering, allows the team to adapt their project to make up for poor scheduling and design decisions. The authors discuss how many scheduling issues can be alleviated by obtaining more precise estimations of the cost of user stories. Although, this skill can typically only be improved through experience, the authors recommended assigning someone to track the progress on user stories for the current iteration. This person, also known as a tracker, should determine if there is a problem with the development of a user story, and if so they should notify the team of the problem. This allows the team to provide input and support or even assign the user story to another pair of programmers that are more suited for the job.

The authors also cover the idea of release level steering, or making adjustments to the project based on the release date of the project. In release level steering, scheduling is an important aspect because it allows you to place more important or riskier stories closer to the beginning of the schedule in order to minimize risk and to have a better working product sooner rather than later.

Discussion:
This reading is important because it talks about the actions that a manager or programming team can take after a schedule has been made. It shows how a schedule should not be set in stone and should be adapted and changed based on the current. On the other hand, this reading also did not present many new ideas on scheduling. Many of the ideas seemed like common sense, such as planning your schedule around the release date of your software. I would assume that such a practice would be common in industry. This reading can be extended to any project that experiences unforeseen problems, which would include the majority of software engineering projects.