The Mythical Man-Month Ch. 18-19

The Mythical Man-Month
Ch. 18-19
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

The author begins chapter 19 by discussing how the mythical man month applies not only to software engineering teams but to teams of all backgrounds. The author then goes into detail about the importance of conceptual integrity in software. Projects with fewer designers typically have more conceptual integrity and are better designed as a result. For example, off the shelf software products often suffer from a low conceptual integrity because they are built to appeal to a wide audience rather than being architected for an express purpose.

The author also discusses the recent success of the WIMP model (Windows, Icons, Menus, Pointers) in computing. However, due to WIMP's limitations the author believes that it will soon be replaced with a new model.

The author also came to an important realization about his initial suggestions to plan to throw the first design away. The author now endorses building the system incrementally, testing each individual component as it is added to the system.

The author ends the reading by noting the dramatic rise of personal computers and software that are available to the public today. When the book was originally written, the author focused on custom built software that would not be available to the public. However, the increased amount of customers that software developers have today allows them to receive a large amount of feedback on their products but also requires them to test more thoroughly before releasing it.

Discussion:

This reading is important because it discusses how software has changed since the book was originally written. The author discusses many important trends in software engineering and offers his ideas on the future. I disagree with the author's ideas that the wimp model will be obsolete. I believe that portions of the model, such as the pointer, may be phased out but many of the core components will stay. This reading can be used by anyone in a software engineering team environment.

The Mythical Man-Month Ch. 16-17

The Mythical Man-Month
Ch. 16-17
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

The author discusses the difficulties related to software engineering and how there is no single "silver bullet" solution that will cause a large increase in productivity. The author splits the characteristics of software engineering into two groups, essential and accidental. Essential characteristics are those that are characteristic of software engineering and will not be fixed in the future. Accidental characteristics are the issues that face software engineering today but are likely to be fixed in the future. There have been several advancements in recent years that have helped to reduce the accidental difficulties related to software engineering, such as high level languages and time sharing.

The author does offer some suggestions to help combat the decreased productivity caused by the essential characteristics of software. For example, buying premade software components can drastically reduce the time spent designing and implementing complex software. The author also suggests using incremental development and prototyping in order to create a better specification of the program before building it.

In chapter 17 the author looks back at the silver bullet paper and observes that no silver bullet has been created yet. The author also goes into detail about the difficulties of correctly using object oriented programming and designing reusable components.

Discussion:

This reading is interesting because it offers a more pessimistic perspective on the advancement of software engineering. I did not like the fact that the original paper was written so long ago that it seemed obsolete. This writing can be used by anyone in the software engineering field looking to increase productivity.

The Mythical Man-Month Ch. 13-15

The Mythical Man-Month
Ch. 13-15
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

Chapter 13 discusses methods for testing, structuring, and debugging software projects. In regards to system structure, the author advocates a top down approach where the components of the system are defined and then broken down during "refinement steps". In regards to debugging and testing, the author believes that components should be debugged separately at first and then integrated one at a time in order to test the system as a whole. The author also advocates writing scaffolding in order to help test the code thoroughly and completely.

Chapter 14 focuses on milestones and how they can be used to keep projects on track. According to the author, milestones should be taken very seriously and missing one could indicate bigger problems in the project. The author suggests that managers should use a PERT chart to help avoid missing milestones. It is also the managers job to encourage communication between team members and to provide disincentives for team members who hold a project back.

Chapter 15 discusses how code can be used not only to communicate with computers but with other programmers as well. In order to communicate ideas effectively through code it must be easy to understand and follow. The author also describes certain items that should always be well documented, including IO formatting, descriptions of algorithms, options, range of input and output, etc. Instead of relying on external forms of documentation, the author suggests writing self documenting code by choosing descriptive variable names, using correct formatting, and including descriptive comments.

Discussion:
This reading is useful because it discusses the need for communication when working in team environments, especially through code. I believe that well written code can save programmers from having to verbally explain their code to everyone that needs to use it. I did think that the author could have spent more time discussing how systems can be designed in order to make testing easier. This reading is useful for managers, designers, and programmers since the reading applies to all three positions.

The Mythical Man-Month Ch. 10-12

The Mythical Man-Month
Ch. 10-12
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

Chapter 10 discusses several methods that teams can use to document projects. A team can collect documentation in the form of objectives, specifications, budgets, schedules, organization charts, space allocations, and estimate prices. The authors uses a university department as an example to show the necessary elements needed to properly document a project. The author ends the chapter by explaining how proper documentation can help reveal problems with the project, such as design errors and inconsistencies.

Chapter 11 returns to the concept of writing prototype systems with the intention to be thrown out before writing the actual system. Since this process takes more time it is likely that requirements will change and new features may be added. To help adapt the code to new requirements the project should be designed in a very modular fashion with the ability to add and remove modules without crashing the system or needing significant rewriting of the code. The author ends the chapter by discussing the importance of writing maintainable code, stating that code maintenance can often be more costly than the development of the code itself.

Chapter 12 discusses tools that teams need to use to finish the job. The author discusses how tools should be shared instead of used by individuals in order to encourage communication. The author also encourages the use of high level languages to increase productivity and communication through code.

Discussion:

This reading is interesting because it discusses the need for documentation and the right tools in order to get the job done. What I did not like about the reading is that all of the ideas seemed like common sense, especially the ones regarding the need for documentation and tools that everyone can use. This reading can be used by teams that are planning on what tools they need to acquire before beginning the development of a software project.

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.

Extreme Programming Installed Ch. 16-18

Extreme programming installed
Chapters 16-18
Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?

Summary:


In Chapters 16-18 the authors provide a detailed list of guidelines on how to create good software. Among these guidelines are to publish progress reports frequently, take stories in order, and practice continuous design. Most of the guidelines were discussed in earlier chapters, and the authors take this time to put the ideas together into a do and don't type list. The authors also go into detail about the importance of being able to estimate how much time a story will take to implement. Although this estimation is never perfect, programmers should be able to give better estimations on the time it will take to implement stories as they become more experienced.


The authors also discuss the importance of scope. Scope should be continuously monitored to make sure that the team is not overwhelmed with stories to be implemented. The easiest way to measure scope is to use a bar graph where each bar represents the number of stories in each iteration and the shaded region of each bar represents the number of completed stories.


Discussion:


This reading is interesting because it brought together a lot of ideas that were represented in earlier chapters of the book. However, I felt that these chapters could have spent less time on the different ways to measure progress. I think that these methods, such as the bar chart, seem like common sense and do not need to be spelled out for the reader. This work can be applied to all projects, not just those that use extreme programming. Many of the guidelines fit into software engineering ideals in general, such as publishing frequent progress reports.

Design of Future Things Ch. 6

The Design of Future Things
Chapter 6
Donald Norman
Editors:?

Summary:


Chapter 6 begins by discussing the recent changes in computer human interaction. The author believes that older machines were more obvious to understand and provided natural feedback to the user. For instance, a dishwasher provides sound feedback for when it is working and when it is done. On the other hand, more modern devices are less obvious in their workings and need to be better designed to make up for this weakness. One way that machines can provide better feedback to users is to provide constant feedback to the user, even when the machine is not malfunctioning. It is also important that this feedback be natural and easily recognizable to the user. The author describes this idea by giving an example of the apple newton. The first iteration of the apple newton translated handwriting into text by looking at the entire writing as a whole whereas the second iteration looked at each letter individually. As a result, the second iteration was able to communicate more effectively with the user because it gives continuous feedback about each character rather than just giving feedback for the entire written text.


The author believes that natural, implicit, and sensible communication is the key to improving the interaction of humans and computers. The feedback to the user should be rich and complex while at the same time being communicated through a natural means. However, the output must also be easily understandable or the user will get no benefit out of it at all.


Discussion:


This reading is interesting because it goes into detail about the aspects of the communication between humans and machines. The author could have given more examples of communication that fit into his ideal communication of machines to humans. This work can be applied to several projects, including my group's project for capstone. In my group's project the user will need some sort of feedback to signal how the kinect is responding to their commands or the user may get frustrated.

Extreme Programming Installed 13-15

Extreme programming installed
Chapters 13-15
Ron Jefferies, Ann Andreson, Chet Hendrickson
Editors: ?

Summary:
In chapter 13 the authors discuss unit tests and their importance in extreme programming. The programming team should use unit tests throughout the entire development life cycle to ensure that the system is tested thoroughly. The authors also suggest using a test driven development approach which involves writing tests before any system code is written. After the system code is written the unit tests should be run to verify the correctness of the code before it is added to the code repository.

Chapter 14 discusses the importance of writing code that effectively communicates ideas. The authors believe that good code should be able to be understood easily without in depth understanding of the specific techniques or algorithms used in the code.

Chapter 15 goes into detail about code repository management practices. In extreme programming, the code repository should be set up in such a way that programmers are able to work on separate pieces of the system individually without worrying about being blocked by other members of the programming team. The authors suggest using a system where code should be unit tested in order to achieve a release candidate state, only at that point can the code be integrated with the working system code. The authors also stress the importance of rapid commits to the repository in order for other team members to get new changes more quickly.

Discussion:
This reading is significant because it goes into detail about the importance of testing and continuous integration. I believe that the authors should have gone into more detail about effectively communicating code. Especially details like choosing variable or function names to communicate the programmers ideas. This work can be applied to any programming team since it involves practices that aid in distributed development.

Design of Future Things Ch. 5

The Design of Future Things
Chapter 5
Donald Norman
Editors:?

Summary: 
In this chapter the author discusses the role that he believes automation should have in our daily lives. According to the author, automation can be extremely useful for tedious or otherwise unwanted tasks. However, the increased use of automation can also increase the amount of time that people spend performing maintenance on the machines that are performing the automation. 

According to the author, automation works best for tasks that are tedious or repetitive. To further his point he uses examples of intelligent homes show the role that automation should play in our daily lives. The author fears that intelligent homes that rely entirely on automation can lead to the inhabitants becoming dependent on the house's decisions. Instead, the author proposes an approach where these intelligent homes should seek to augment the inhabitant's lives rather that automate them. In this approach, the inhabitants would have total control over the machines while they are using them. 


Discussion:

This reading is significant because it weighs the pros and cons of automation in the home. However, I do think that the author's stance on common tasks is a little extreme. Many of the tasks that he would see to be augmented rather than automated, I would rather see automated. Other people can apply this work when they are designing intelligent homes. In addition, these ideas can be applied to software as well. For instance, software engineers could use this work to determine what software tasks should be completely automated and which ones should ask the user for their input.

Extreme Programming Installed Ch. 10-12

Extreme programming installed
Chapters 10-12
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

 Summary:
In chapter 10 the authors disuss quick design sessions. In these sessions the programming team meets to come up with a design for tasks that they are unsure how to implement. Ideally, the team should be able to think of a design within 30 minutes and use that design to begin coding the task. A quick design session should utilize all of the programming team member's skills to come up with a solution.

In chapter 11 the authors discuss aspects of the programming phase. In extreme programming all coding should be done in pairs, with one programmer doing the actual coding and another team member watching and providing input. Extreme programming also requires the pair to write unit tests before they begin and coding on the task. This allows the pair to assure the validity of their code before they commit it to the repository for the rest of the programming team to use. According to the authors, no programming team member should assume ownership of any piece of code. Any team member should be free to modify any line of code from anywhere in the project. This encourages team members to understand the system as a whole, rather than just learning the individual tasks that they are assigned. In order to facilitate the team's collective understanding of the system, a coding standard should be established. The coding standard should address aspects of the code including commenting, capitalization, indentation, naming conventions, and so on. Commenting should not be used to explain poorly written code, rather the code should be self explanatory and easy to follow, using comments only for special cases.

Chapter 12 returns to the idea of pair programming and discusses it in detail. The idea behind pair programming is that it produces better code than is produced by two people individually writing code. Pair programming also has the added benefit of furthering the team's collective knowledge of the system since both of the team members participating in pair programming will understand the piece of code that they are coding. The team member not writing the code, the partner, is tasked with spotting errors and  giving ideas and feedback to the driver, the team member that is writing the code. The driver needs to accept feedback and actively engage with the partner in order for both members to be actively engaged in the coding process. The authors also suggest that the partner and driver switch places occasionally in order for both members to remain interested in the project.

Discussion:
The main part that I find interesting about this reading is the idea of pair programming. I have used pair programming before at work and I can attest to its usefulness. Hearing more about the advantages that it can bring makes me wish that more team projects at A&M encouraged the use of pair programming. This reading does not have any faults, however I would have liked to see more about the quick design session discussed in chapter 10. This reading can be applied to our project in capstone. Right now the team is very divided on what tasks they are assigned, which will most likely result in team members becoming the resident expert on a particular topic. If we were to use pair programming it would allow more team members to understand different aspects of the project.

Design of Future Things Ch. 4

The Design of Future Things
Chapter 4
Donald Norman
Editors:?

Summary:
In this chapter the author discusses how humans have become dependent on machines, causing humans to become the servants of machines. Humans rely on machines to do tedious jobs, while they themselves do not understand how the machine works. This leaves them to supervise the machines to make sure that the job is accomplished. This causes humans to spend a great deal of time on machine maintenance and supervision. 

The amount of supervision that machines require is further increased due to the lack of communication between humans and machines. The author suggests that machines will perform best when the humans they are interacting with receive specialized training that teaches them about the functions and details of the machine. For example, in an industrialized setting, a machine operator would be trained on how to effectively utilize any machines that he is interacting with and the machine would be able to perform its job well. However, in a household environment a machine operator would receive no special training on how to use a machine and the machine would not be able to perform its job as well. Because machines cannot effectively communicate with humans, the humans need to learn more about the machines and all of their intricacies before they can work together effectively.


The author also discusses the problem of  designing machines to have automation but not full automation. In instances where machines do not have full automation, they may return control to the operator at any time. This can be dangerous since the operator may not be paying attention or may not have enough knowledge about the situation to react effectively. The author believes that machines should either be fully automated, requiring no human intervention, or have no automation at all. Examples of full automation that the author discusses are swarms and platoons. In a swarm system machines communicate with each other to move in a common direction, while in platoon systems machines follow the direction of a designated leader.


Discussion:
I think that this reading is significant because it shows how much time humans spend monitoring and babysitting machines. It also shows the risk that having semi automated machines can pose, especially in industrialized or other dangerous areas. I think that the author failed to address the merits of semi automated systems while only addressing their flaws. This reading can be applied to many areas where humans relay on machine automation. A good idea would be to design systems around the fact that machines will be ceding control to humans in the vent of an emergency. Such systems could inform the operator about the situation and even offer guidance.

Extreme Programming Installed Ch. 7-9

Extreme programming installed
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

 Summary:
Chapter 7 focuses on the advantages of having a short release cycle. Short release cycles allow the team to supply the customer with working builds at each iteration. This allows for the customer to provide timely and useful feedback to the programming team. In turn the programming team is able to take this feedback and use it to iteratively shape the system to the customer's needs.

Chapter 8 focuses on effectively planning release schedules. A release can consist of one or more iterations with each iteration implementing one or many stories. It is important to decide what stories are included in each release in order to increase the business value of the release while still releasing it in a timely manner. The process of determining these stories starts with the exploration phase, where the customer provides stories to the programming team and the programming team provides feedback on the stories. Then, in the commitment phase, the programming team members are assigned stories to work on and estimate how much time it will take to complete all of their assigned stories. A point value is then assigned to each story, signifying how hard the story will be to implement. Finally, in the steering stage, the customer picks which stories to implement after receiving feedback on the difficulty of each story.

Chapter 9 focuses on iteration planning, or the process of assigning user stories to members of the programming team for each iteration. An iteration planning meeting starts with the customer presenting user stories to the programming team. After the team members have heard all of the user stories, they are expected to collectively brainstorm engineering tasks. Each programming team member is expected to help generate as many ideas as possible in order to benefit the team. After all the stories have been explained to the programming team, the team members should sign up for stories that they wish to implement.

Discussion:
This section of the reading was interesting because it brought up many useful ideas, such as team brainstorming and discussing user stories with the customer. I fell that team brainstorming would help gather the collective knowledge of the group in order to help avoid as many engineering road blocks as possible. Discussing user stories with the customer seems to be critical in order to start the project off in the right direction so as to not waste any time or effort. I feel like the authors should have gone over some of the ways to provide continuous or iterative updates to the user. For example, using automated build systems to remotely update the software on the customer's site. This reading could be applied to our project proposals meetings. We volunteered for specific tasks, and determined how long each task would take. However, It would be useful to engage in a team brainstorming discussion before we begin the project.

Design of Future Things Ch. 3

The Design of Future Things
Chapter 2
Donald Norman
Editors:

Summary:

The author begins the chapter by addressing the problem of communication between humans and machines. The author does not like the fact that machines predominantly communicate to their users through loud noises or flashing lights. This becomes a problem when many machines are giving signals to the user at the same time, preventing the user to be unable to react to the machines in an appropriate time. The author suggests that this problem can be alleviated by having the machine emit and ambient sound that would gradually increase in volume as the machine gets closer to failing.

According to the author, machines should exhibit features that humans can easily identify and use. This allows users to be able to interact with machines without needing an explanation beforehand. When a user is familiar with more aspects of the machine then the machine should grant more control to the user. On the other hand, if a user is unfamilar with several aspects of the machine then the machine should have more control than the user. Users should be able to determine the balance of control between machines and themselves through the use of "playbooks". These playbooks would determine what operations the user has control over and what operations the machine should handle. Users should be able to adjust these playbooks so that they know exactly what their responsibilities are as well as the responsibilities of the machine. The machine should also display the current playbook to the user so that the user never has to guess what responsibilities they have.

The author then comments on the fact that modern machines have almost entirely removed the risk factor out of most situations. The risk component of these situations can actually make operations more safe due to the fact that operators will take less risks when there is more at stake.

Discussion:

This reading is significant because it addresses the information overload that can occur when a person uses too many machines simultaneously. This is an important problem when devices need to communicate to the user. However, I do not think that an ambient sound coming from all of the devices that I am operating is the best idea. I would prefer a system where the user is able to adjust what types of warning noises are generated in what types of situations and at what volume. I think that this reading's ideas can be applied to systems where there is a delicate balance of power between the machine and the user. Some examples may be autopilots on airplanes. The pilot should be able to see at all times what operations the autopilot is handling and what operations the autopilot expects the pilot to handle.

Extreme Programming Installed Ch. 4-6

Extreme programming installed
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

Summary:

The authors began this section by discussing the various aspects of user stories from their creation to implementation. To begin the user story process, the programmers and customer sit in a room with a box full of index cards. Then the customer writes down a story that explains a small section of the functionality of the system. The programmers and customer then work together to refine the story by asking questions and addressing concerns. This relates back to the in person communication that is a core aspect of extreme programming.

The authors then discuss acceptance tests, tests provided by the customer to ensure the system meets all of their requirements. Programmers should utilize these acceptance tests throughout the entire development process. This will allow them to ensure that the product meets the specifications of the customer at all times. The customer should also be able to add or remove acceptance tests at any point in time. A good way to manage this process is to use automated testing, where builds are automatically run through a program that will verify that they meet the current set of acceptance tests.

The last chapter focuses on how important it is for programmers to be able to estimate the difficulty of user stories. This allows the programming team to provide useful feedback to the customer as well as plan their schedule to avoid roadblocks and keep the development process as smooth as possible. The authors recommend using a point system, where each story is allotted a certain amount of points based on its difficulty. The programmers can then set a budget on how many points they are able to complete in a certain time period. If the user stories presented to the team exceed the budget then the customer would need to remove or modify stories.

Discussion:

I like the idea of using user stories to communicate the desires of the customer to the programming team as well as the concerns of the programming team back to the customer. Often, customers want every feature possible for a low cost and a short development time. Having the team meet with the customer in person can help to encourage communication on project scope and cost from the very beginning. I wish that the authors would have focused more on the discussion of how programmers and customers can negotiate user stories. Such as what to do in certain unplanned situations where the customer refuses to modify stories. I think that the ideas in this reading could be applied to the projects that I work on where a customer is involved. Having the face to face communication at the start of a project could really help me to understand what the customer actually wants from the end product.

The Design of Future Things Ch. 2

The Design of Future Things
Chapter 2
Donald Norman
Editors:

Summary:
The second chapter continues with the idea that the main problem with computer human interaction is the lack of communication between machines and their users. The author extends this idea by explaining how most users have no idea how the machines that they are using truly work. To the user these machines just seem to work, and that leaves a communication gap between the two parties.


The author then shifts his focus to the aspects of the human brain and how each relates to machines. According to the author, the human brain can be separated into the visceral, behavioral, and reflective components. While machines are able to demonstrate visceral and behavioral components, they have not yet reached the capacity to demonstrate the reflective component. The author then explains how machines could reach the reflective level through augmentation. As a result, the machine would inherit much of the subconscious, thinking work that is generally reserved for the user , whereas the user would simply make high level commands to the machine.


Discussion:


I think that the author is doing a great job at building on his examples from the previous chapters. It gives the readings a sense of continuity and doesn't overload the reader with examples. On the other hand, this chapter seemed to be less flowing and seemed to jump around from idea to idea with little transition or explanation. The ideas presented in this chapter could be extended to improve interfaces for computer human interaction, Like the author described, there needs to be more communication between users and machines. Allowing the user to see why a machine made a certain choice would definitely be a step in the right direction.

Extreme programming installed Ch. 1-3

Extreme programming installed
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

Summary:

The first chapter mainly focused on the roles and interactions of the key people in the extreme programming method: the programmers, customer, and manager. A customer should work to define the business value of the software that they want to be produced by writing stories, written examples that define an example usage of some aspect of the software. Programmers then interpret these stories to build software that behaves in a way that matches the stories of the customer. Customers can also define acceptance tests to determine whether or not the software behaves the way that they believe that it should. The main goal of a manager is to remove obstacles from the path of the programmers. Managers should plan meetings, resolve conflicts, encourage communication, and provide the programmers with all the tools that they require to build software effectively and efficiently.


Chapter 2 discusses the development cycle that takes place between customers and programmers. Customers provide stories or feature requests in order to define the value of the software and programmers in return build the defined values into the system and present it to the customer. From there, the customer can provide feedback to the programmers and further define the value of the software.

Chapter3 discusses the importance of an on site customer. Having an on site customer is critical because it allows immediate and effective communication between the programmers and the customer. It allows constant feedback on the direction that the software is heading in and allows for the customer to make sure that the software is behaving the way that they believe that it should be. Having an on site customer can help prevent  making assumptions when writing code and can help prevent road blocks that occur when the programmers are waiting on an answer from the customer before they can continue developing.


Discussion:

This reading was significant because it explained many aspects of extreme programming that may seem strange to software developers. Ideas like having an on site customer or pair programming can really improve communication when developing software and can help remove the incorrect interpretation of the customer's requirements.

The only "fault" that I could find with the reading is that the author did not go into depth about many of the concepts that he mentioned, such as pair programming and acceptance tests. However, these topics are most likely discussed in greater depth later in the book.

This book could be extended to improve upon some of the shortcomings of extreme programming. Such as the problem of having software that is more feature and code driven rather than design driven. Continually refactoring and providing a working product is great until a design problem comes up that could have been avoided by coming up with an overall design for all features before coding began.

Design of Future Things Ch. 1

Design of future things by Donald Norman.

Summary:

The first chapter focused on the need for computer human interaction to change as technology becomes more and more sophisticated. The author believes that active communication or dialogue between computers and machines is the key to designing systems that will assist humans rather than become a hindrance to them. Another key aspect of designing future devices that was discussed was the need for a more natural interaction between humans and machines. According to the author, machines should be designed around how people behave.
That is, machines should serve to assist humans without becoming intrusive or invasive. In order for humans and machines to communicate naturally they need to be able to relate to one another and leverage each ones strengths.


Discussion:

This paper is interesting because it takes a critical view on the design of many of todays systems. Many of the points that the author raises about the behavior of automated systems in cars show how unintelligent most modern systems really are.
While the author makes several valid points that should be taken into consideration when designing a system, he offers no way of implementing the smart systems that he proposes. All he offers is the fact that several research laboratories are working on similar systems right now. Many of the designs that he sees as necessary are impossible with current technology.
Possible future work relating to this chapter would be the implementation of systems that are able to better communicate to the user. A more attainable goal would be systems that are able to react to unforeseen situations. Inference machines could be used to help achieve these goals, however there are always going to be situations that machines can not react to. If there is an unknown input that the machine does not know how to process then the machine would not be able to make a logical decision.

Introduction

My name is Warren Kiser. After graduating I will start working for FactSet Research Systems in Norwalk, CT. My computing interests include software engineering, software design, computer graphics, and user interface design. Recently my greatest computing strength has been Java and all of its related tools. My favorite computer science project was the human body animation project from computer graphics. My least favorite was the wumpus world project from A.I. I see the most important tech development in the last 5 years to be Android, because it allowed for the rapid advancement of smartphones. My only pet peeve in regards to coding style is when people dont put a line break between a function definition and the open brace.