The Mythical Man-Month Ch 18-19

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 18 discussed the main points from the 1975 edition of The Mythical Man-Month in outline form. This included bulleted points of the most important points from each chapter that the author believes to be true, along with the author's commentary. Most of the points were thoroughly discussed in previous chapters.

The cover to the 1975 edition of The Mythical Man-Month. Source: http://var.pulist.net/

Chapter 19 discussed the differences between the 1975 edition of The Mythical Man-Month the state of things 20 years later. It considered the reason why the book is still relevant. Then, the central arguments of the book were considered: the importance of conceptual integrity, the need for an architect on the design to ensure conceptual integrity (including his separation from implementation and the partitioning off of subsystems. The Second System effect was discussed more, taking into account challenges such as designing for large-user sets, dealing with featuritis, the need to explicitly define the user set, and the benefit that defining frequencies of the user set has on the design. The WIMP (Windows, Icons, Menus, Pointing) interface was discussed along with its good and bad points, such as conceptual integrity via a metaphor, user power, and the fact that the author believes it will eventually become obsolete. The author encourages incremental building instead of the waterfall method that is supported throughout the book. Finally, he discusses the importance of people to a project, data that supports his conclusions, the effect that new technology has had (including the tendency to buy and build new software), and what he believes will occur in the future.


Discussion
I thought that chapter 18 was a good summary of the current book, although after having already read the book, it seemed a little unnecessary. I did like the chapter 19 discussed the points made throughout the book in a different light, encouraging the reader to follow practices that the author believes is good given new data and new technology. However, the author debunked many of the things said throughout the book by switching to supporting the incremental build instead of the waterfall method. I thought this made some of the chapters and points that he had made rather pointless, so I wonder what the point of reading them was in the first place? Either way, though, there were some very good points made within this book. I was previously unaware of many of the things discussed (such as the second system effect), so I believe that applying this information to future projects will be very helpful, including incremental programming, being aware of featuritis, and keeping many of the organizational structures that were recommended in mind.

The Mythical Man-Month Ch 16-17

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
The first chapter was "No Silver Bullet", a paper written in 1986 about the state of programming and the lack of a magical solution to improve programs by an order-of-magnitude. There are two major types of difficulties with software: essential (difficulties that are inherent in the nature of software) and accidental (those difficulties that attend to production but are not inherent). Complexity, changeability, conformity, and invisibility are all essential challenges that come with programming and must be considered. Breakthroughs that have been helpful in improving accidental issues associated with programming include high level languages, time-sharing, and unified programming environments. The author discussed topics that show promise for improving software, such as AI (he did not think this would be helpful) and object-oriented programming. The most promising improvements are the fact that general software can now be bought for cheap, incremental development, and developing great software designers.

There is no silver bullet, magical solution. Source: socialwants.com

The second chapter was the author's evaluation of the "No Silver Bullet" paper. He defines many of the terms used in the paper in terms that he finds to be more understandable and evaluates a few other peoples' critiques of "No Silver Bullet", including the idea that productivity follows from quality of software. The buying instead of  building of general software is recommended and object-oriented techniques are praised. The idea of reusing code is considered, which requires more expense up front and larger vocabularies to learn.


Discussion
The "No Silver Bullet" paper presented some interesting ideas, such as the idea that there is no magical solution to solve all software issues. However, the paper was so out-of-date for present time that it made it seem rather pointless to read. The object-oriented programming discussion was outdated since it is currently in use, and the argument that graphical software is pointless due to small screens is rather moot now. However, I did like the idea of incremental development, as it seems like what we are currently doing with our Capstone project, incrementally issuing working versions of our product that slowly increase in functionality.

Also, the author's discussion about the paper seemed rather odd, since he was critiquing critiques of the paper. Also, the even these arguments were slightly outdated, especially the arguments that object-oriented programming can be infeasible due to training costs; today most programmers are taught object-oriented programming from the start. Once again, though there were some helpful points, including the suggestion to buy software instead of creating specialized, expensive software tools. This information could be applied to future products to keep in mind that there is no magical solution, but there are many helpful tools available to use.

The Mythical Man-Month Ch 13-15

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 12 discussed how the parts of a program fit into the whole. It mostly focused on eliminating bugs. It is suggested that to reduce bugs in a program, the definition should be bug-proofed, the specifications should be tested by an outside testing group, a top-down design should be used whereby there are refinement steps to breakdown large steps of the solution into smaller modules, and structured programming should be used. The cycle of debugging procedures was discussed, going from on-machine debugging with carefully designed debugging procedures to having test cases that are often not carefully planned out but can be run multiple times quickly. The hardest part of building is the system test, which should use debugged components, programs and data built for debugging purposes, someone to control the changes, incremental component adding, and quantized updates.

An example of top-down design. In this case, for writing an introduction. However, the idea can be applied to desigining programs. Source: leo.stcloudstate.edu

Chapter 14 discussed to incident of shifting schedules. There should be a schedule that contains a list of milestones, each with a concrete event and date. to make it easier to stick to the schedule. PERT charts are helpful for keeping track of progress. The fact that the manager is not inclined to let his boss know about the gradual slipping of the schedule was also discussed, and the book suggests that the boss must change his behavior to encourage the managers to keep him updated.

Chapter 15 discussed the user view of the program, and the ways different project documentations must be presented depending on the situation. The book emphasizes that flow charts are only helpful if they are one page, and that they usually are not done until afterward. Finally, self-documenting programs were discussed, whereby the program's documentation occurs within the code itself by use of commenting and proper naming of variables.

Discussion
I especially liked that the book suggested that showing someone how a job is done is much more successful than just telling them how to do it. I also prefer the self-documenting approach to writing tons of unhelpful documentation to accompany the code. I think both of these ideas should be used in future work, to make code easier to read and modify and to show users how to use the program in a proper way. I did, however, think the discussion about managers telling the boss about schedule slips to be a little unrealistic, since many bosses would not be very amenable to hearing that.

The Mythical Man-Month Ch 10-12

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
The need for documents was discussed, presenting the different kinds of documents that are needed for various jobs. These need to answer what, when, how much, where, and who. Generally, these include objectives (defining what needs to be met), specifications (including the manual), schedule, budget (forces decisions to be made), organization chart (describing those working on the project), and space allocations. Formal documentation is necessary to have decisions in writing for easier communication and to give the manager a way to see where he is and changes are needed.

The idea of planning to throw away a system was discussed, since the first system is generally only barely usable. Change must be accepted as a part of building a system, since many things can change, including the user's needs and requirements. As development proceeds, the number of changes necessary increases. To plan for changes, a system must have careful modularization, extensive subroutining, precise and complete definitions of intermodule interfaces, complete documentation, use of a high-level language, and version numbers. There needs to be a proper amount of management control in order to create an organization that allows for change in the program. Program maintenance is necessary once the product has been released, and bugs often reappear in later releases since fixing one defect has a good chance of creating a different one.

The first system should be planned to throw away. Source: blogs.bgsu.edu

Tools are required for creating programming projects, such as a computer facility, operating system, language, utilities, debugging aids, test-case generations, and text-processing system. There should be one toolmaker per team that masters the common tools to explain to others and builds special tools that are necessary. Target machines are those that the software is written for, and require a target facility and scheduling in order to properly test the program. Vehicle machines are those that provide services used in building the system, and require simulators for stability, compiler and assemblers, program libraries, program tools, and a documentation system. Finally, the importance of using a high-level language was discussed, since it increases productivity and debugging speed.



Discussion
I think these chapters presented some very good points about the actual building process of a programming project. Some of the suggestions and comments were outdated and the job hierarchy of managers and such that was constantly being used was a little difficult to understand since I have not had much experience in a work place. This made parts of the chapters confusing, but overall, the points made were useful. The importance of documentation, constantly changing and improving a system, and having the required tools for programming were good points, and I believe these could be applied to future projects to improve them, such as making sure to have structured documentation so that everyone in the group knows what is going on.

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.

Design of Future Things Ch 6

Reference Information

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary
This chapter discussed the necessity of communicating with machines. Communication allows people to form mental and conceptual models that provide them with clues to troubleshoot when something goes wrong, to know what to expect next, and to allow us to experiment with the machine. While mechanical devices are generally self-explanatory due to natural indicators, the indicators are becoming more hidden and silent, making it more difficult to use machines. Because of this, it falls to the designer to reveal how the machine works to the user.

Communication, understanding, and explanation are the keys to working with intelligent agents. Feedback is necessary for reassurance if the system is working correctly, and help if the system is not working. Therefore, a good design should provide continual awareness of the system's state without annoying the user.

Feedback provides informative clues about what's happening and what we should do. It includes natural sounds (that work based on subtle differences of sound). The idea is transition to a more supportive form of interaction than confusing lights and beeps, one that guides the user to decide how to respond or to reassure them that no action is required. It has to be continuous and unobtrusive, requiring little attention on the user's end.

A bad design of communication -- confusing lights to signal warnings.  At first glance, how would you know what a light was supposed to be telling you?
Source: www.stockphotopro.com

Natural interaction includes implicit communication, natural sounds and events, understandable signals, and natural mappings between display devices and their controls. Natural signals are important to keep people aware of what's happening in their environment, just enough to provide feedback but not enough to overload the user. Some good rules for interaction were provided, including: be predictable, provide natural signals, provide a good conceptual model, and exploit natural mappings.

Discussion
I think this chapter raised some very good points about design issues and how to make systems easier to use by providing a communication channel between the machine and the user. However, I felt as if I had read this chapter before. It seems to be a mix of previous chapters in both this book and Design of Everyday Things, so mostly, it felt rather pointless to read.

Extreme Programming Installed Ch 16-18

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 16 outlined things that you should and should not do when practicing the extreme programming approach to programming. This list includes things like don't try to design the whole system before you start implementing it, don't produce voluminous design documents at the beginning, focus on communication, and don't build for tomorrow. In addition, the aspects of a good program are listed: well-designed, flexibly structured, properly documented, tested, and meeting known and documented requirements.

Chapter 17 discussed how with each iteration, experience is gained that can be put towards improving estimates of future stories. The important concepts of task estimation are listed: estimate each task that you sign up for; estimate time you'll spend working; pay attention to the actual time spent working; then evaluate how the estimation time compared with the actual time.

Chapter 18 discussed how to evaluate resources, scope, quality, and time associated with a project. This evaluation lets those people working on a project know where the project currently is, and how well it is doing. Examples of each of the indicators are provided, as well as example graphs of how to plot the actual information associated with each project aspect in order to see how progress is going. For example, to evaluate quality, it is suggested to graph unit test scores vs. time.

An example graph evaluating quality by the acceptance test scores. Source: Book.

Discussion
I find it helpful that most of these chapters were just the authors outlining the main points that readers need to know about Extreme Programming and how to successfully use it. In addition, I think it's very useful that example graphs and suggestions were provided for evaluating project progress, which is very useful to us at this point in time. Since we have been working on our group project for a while now, it is getting to the point where it would be helpful to have more of an indicator of how well we are doing and an estimate of what pace we are currently working at. Some of these graphs seem like they could be useful for us to employ to help with this.

Design of Future Things Ch 5

Reference Information

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary

This chapter discussed the role of automation, explaining that automation is needed to eliminate the dull, the dangerous, and the dirty. However, automation changes the systems already in place, changing the way work is done, changing existing jobs, and changing necessary functions. A lot of the time, it creates more work than before, just allowing the work to be done in a different time frame than previously.

The author discussed smart homes versus homes that make people smart, describing the differences between automation and intelligent augmentation. Autonomy attempts to infer the intentions of people, whereas intelligent augmentation provides useful tools but lets people decide when and where they will use them. The author then emphasized the need to recognize possible failures.

Discussion

I found this chapter very interesting since it described the small differences between automation and augmentation. While most people think that the future holds many automated things, augmentation would be more useful in many situations since it allows user choice. I liked the discussion about the different kinds of houses, and I thought the idea of the interactive message board was pretty cool.  I think that many of the ideas that the author presented should be kept in mind when designing new technologies, such as the need to allow users to make their own choices in some situations.

A picture of the interactive message board. Source: research.microsoft.com

Extreme Programming Installed Ch 13-15

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 13 discussed unit tests, recommending that everything that could possibly break should be tested. Unit tests are automated tests, and they must run perfectly all of the time. Since code is shared, unit tests are necessary to keep the rapid pace of coding working without resulting in broken code. Tests are written from the beginning, and continually written throughout the coding process. Code is only released once all unit tests run at 100%. Tests are created before ever actually writing the code, so sometimes stub methods/objects are necessary if someone else is responsible for the unwritten code.

Chapter 14 discussed the model of testing first by intention. Instead of thinking about how to do something, the programmer should think about what has to be done. This expressed intention instead of the algorithm within the code.

Chapter 15 described the process of releasing changes. It is an important part of making collective code ownership work, so that other programmers on the team can have working code released to them in a timely manner. When a programming pair writes tests and code, once all tests are working 100%, the code should be released to the team's repository. If there are conflicts between revisions, the conflicts should be fixed on an integration machine, where the pair resolves all conflicts, makes sure all unit tests still work completely, then releases the revised code to the repository.


Discussion
This reading is interesting because it brings up some very useful concepts for programming. Unit tests seem as if they would become annoying to the programmer, always having to test every little thing before the code is even written for it. While it seems as if it would be a waste of time, I can see how unit tests would actually be very useful. It probably takes less time to write a unit test than it does to fix large errors that would come up without them. In addition, the discussion about releasing changes was informative, as we are currently using a repository for our project. Some of the suggestions, such as carefully fixing conflicts and releasing very often, are good ideas that we should probably include in our own programming practices.

Source: blog.dileno.com

Design of Future Things Ch 4

Reference Information

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary
This chapter described the problems of automating machines. The author stated that people are becoming the servants of their machines, but that it's too late to go back to living without machines. After some new technology is first deployed, it always delivers previously unseen benefits, with problems not originally thought of. While intelligent devices can interact well with the physical world and other devices, they cannot interact well with humans.

The author discussed potential automations, such as cars that drive themselves and entertainment systems that decide what you should watch. He mostly focused on the automobile, stating that it is the most advanced area of automation that impacts our lives. The difficulty is automating the driving process while still avoiding the problem of over-automation. The author discussed cars communicating with each other wirelessly, forming swarms or platoons to travel in so that their communications help each other to travel together.

A depiction of a car communicating about an accident to other cars.  Source: blogs.cars.com

Discussion
Most of what this author seems to say is just rehashing what he said in previous chapters. I understand that repetition is necessary for understanding, but it gets rather annoying to keep reading the same things. While he did bring up some good points involving automation, he seems to be against automation in one section of the chapter, then for it in the next.  Also, the swarm of cars seems like a good idea in theory; however, when technology is capable of it, I feel that in practice it would be a horrible idea. The cars would have to be entirely automated, because I can see the unpredictability of humans causing cars to suddenly swerve out of the swarms, causing massive accidents.

Extreme Programming Installed Ch 10-12

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 10 discussed the quick design session, a technique to help programmers move forward with courage. After the story is broken into tasks, the team can proceed to test-first programming, but if more clarification is needed, a quick design session can be held. The session should only be a few minutes long, and involves sketching out the design. The idea is to understand what is about to be done, and how to implement or change the processes involved in order to achieve the task at hand.

The next chapter discussed how programming should go about being done in Extreme Programming. Paired programming is established, and each pair works on one task at a time. After completing each task, it is integrated with the existing software, all unit tests are run, then the tests and code are released into the repository to complete continuous integration. In addition, collective code ownership occurs, where code is shared and owned by all so that anyone can easily make changes to whatever they might need changed. Simple design is used when programming, and refactoring occurs often such that code is always kept simple. Finally, a coding standard must be established so that everyone's collaborative code is similar.

Chapter 12 discussed paired programming in detail, where the person programming is the "driver" and the person observing and  keeping track of things the driver can't keep track of is the "partner". The partner makes sure the driver's strategy is consistent, and the driver makes sure the partner is actively engaged. They each switch roles every once and a while. The idea is that through paired programming, better code can be generated faster.


Discussion
I like the practices put forward for programmers, such as sticking to a coding standard (ugly code gets really annoying to look at!) and having continuous integration. However, I feel that some of the ideas would just be confusing or time-consuming in practice. For example, collective code ownership is great in theory, but what if someone misunderstands how someone else's code is working, modifies it with that misunderstanding, and then either breaks the code piece they changed, or breaks many other classes because of it. It seems like it could become a major issue if that happened. Also, paired programming just seems like it would waste more time than it would gain. There are many people that when put with others, tend to just talk or get distracted, which would lead to the programmer being distracted, thus accomplishing nothing. Also, if one of the people doesn't understand what's going on, the other one would spend most of their time explaining it instead of getting work done. I do see the benefits though, where one programmer can catch the other's mistake and such, but many computer scientists just prefer to work alone.

A comic mocking the potential distractions pair programming offers. Source: agilegamedevelopment.com

Design of Future Things Ch 3

Reference Information 

Title: Design of Future Things

Author: Don Norman

Publisher: Basic Books, May 2009

Summary

This chapter discussed the importance and implications of natural interaction. Many designs incorporate the use of signals, such as beeps and flashing lights, to inform users that something has happened. This author argues that instead, designers should use natural signals that humans are already used to, such as noises that already occur with a specific process. Natural signals such as environmental sounds and lights occur within the background, making them less intrusive, and are easier to identify, as identification generally happens subconsciously.

A whistling tea kettle - an example of a natural signal. Source:  www.theburningbiscuit.com

Implicit communication is discussed, which are natural side effects that can be interpreted by others and inform without interruption or need for conscious thought. The author brings up a design problem of understanding how to enhance a sound's value while minimizing its annoyance. The author then describes affordances, or communication between the designer and the user of a product. These explain perceptions of the world, and are not fixed properties. Providing effective, perceivable affordances is important in design, since it is necessary to show how to interact with a system, and how the system might interact with the world.

Finally, the author discusses predictability and natural safety. He states that a machine should behave predictably and let the person respond appropriately, so that the two can properly work together. Also, the idea of natural safety is based on the fact that as safety is increased, people tend to take more risks. Therefore, designers need to make dangerous activities look more dangerous, while actually making them safer.

Summary

I find the idea that the safer a task is, the more risks people tend to take with it to be very interesting. In theory, making something safer would be beneficial, but it is true that people tend to get complacent when the risk is removed, allowing more risks to be taken. Also, I found the example about bicyclists avoiding walkers to be very thought-provoking. Instead of trying to avoid the bicyclists while the bicyclists try to avoid the walkers, which always ends up with both moving in the same direction and hitting each other, it makes sense to give the responsibility to one of the two. In this case, the bicyclists present more danger, and therefore should be more careful, so acting predictably allows them to take the responsibility of avoiding people.

Extreme Programming Installed Ch 7-9

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary

Chapter 7 discussed the idea of having small releases in Extreme Programming. They provide early benefits to the customer with early feedback to the programmer. Early releases allow direction to be changed throughout the project, and provides an actual, working version of the product to the customer.

Chapter 8 discussed the customer's role in product releases. It is up to the customer to control the scope of each release, and to decide what needs to be done and what should be deferred. This should be decided based on the amount of business value, difficulty of implementation, and the team's implementation velocity. The exploration phase of planning release consists of writing user stories, and letting the programmers experiment with ways of building the system. This informs them how costly the stories and features will be. From this, the project velocity can be determined, which is how many points the programmers can complete within a given period of time. Based on this velocity, stories can be selected for the first release.

Chapter 9 discussed iteration planning, where the development team plans a few weeks at a time with clear objectives and solid estimates. The customer selects work that will maximize business value and programmers agree to work on stories defined by the customer in the order requested by the customer. Planning is done in short iterations, so that tight estimations of work effort can be created. The process of iteration planning is: Customer considers business value of each story and programmers assign difficulty points with an estimated velocity, the customer prepares for the iteration planning meeting by selecting stories whose points add up to the project velocity, then the customer presents and describes stories while the programmers sign up for work and estimate tasks. This allows for discussion and understanding to take place.

An example of iteration planning, whereby tasks are associated with points and programmers sign up for tasks.

Summary

I agree that small, working releases are a good idea when programming, so that the program will always work in some way and the customer can see what's being done to make sure that the programmers have the right idea. Also, I like how in iteration planning, programmers are encouraged to sign up for stories or tasks, estimating how long they will take. When the programmers have the ability to choose what parts of a program that they work on, it encourages interest in the topic, which in turn increases the programmer's productivity.

Design of Future Things Ch 2

Reference Information 
Title: Design of Future Things
Author: Don Norman
Publisher: Basic Books, May 2009

Summary
This second chapter discussed the psychology of people and machines. The author mentioned that humans generally use anthropomorphism to apply human attributes to machines. With changing technology, the design of such machines is evolving to become autonomous or semi-autonomous, where they can create their own assessments of situations and make their own decisions. Generally, manufacturers want users to believe and trust in the designer, not questioning the machine or how it's working.

The author looked at the design of brains, comparing humans versus machine. While machines are faster at processing, the processing is much less parallel as compared to the human brain processes. Humans tend to see relationships, patterns, and similarities between objects, and generally contain common sense, while machines do not. However, both human and machine must succumb to the same worldly demands and requirements, such as the need to function effectively, reliably, and safely in the real world. To further discuss brains, the author describes the three important levels of processing in the brain: visceral (subconscious processing determined by biological heritage), behavioral (learned skills that are mostly subconscious and control behavior), and reflective (conscious and self-aware; contains analysis of past and future dreams).

Symbiotic relationships are discussed, as in considering the car+human or horse+human to be a whole system, it becomes a conscious, emotional, intelligent system with the car being visceral, the driver reflective, and both being behavioral. However, there are some currently irreplicable capabilities of humans, such as emotions, perception, and the common ground aspect that is needed for proper communication.

Discussion
The author explained many differences and similarities of machines, emphasizing his point with examples of future systems such as a refrigerator that puts you on a diet. The examples were amusing, but I could see how once the technology caught up, someone would think this was a good idea and implement it, eventually leading to some interesting conundrums like refrigerators starving their overweight owners. I like how the author provided his own opinions about how such machines could be designed to be useful and accepted by people as a whole. His opinion was that if machines suggested instead of demanded an outcome it would be better. For example, instead of the refrigerator denying access to food, it could simply suggest not to eat it, or even make fun of the person to offer some stimulation for not eating it. In addition, better communication between humans and machines needs to be established, so that if the assumptions and common factors between the two are made clear, it should be easier to actually communicate. I agree with the author's opinion.

An ordinary, non-controlling refrigerator. Source:  www.goodmanappliance.com

Extreme Programming Installed Ch 4-6

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 4 discusses user stories, which are short descriptions of the behavior of the system from the viewpoint of the user. It is the customer's responsibility to create the stories to let the programmers know what's needed in order to get the most possible value out of programming. The user story acts as a mode of communication between customer and programmer. Stories can be split or expanded upon based on the amount of time they will take or estimated complexity.

An example of a user story depicting the need for a "Search and Replace" feature in a word processor. Source: www.stellman-greene.com

Chapter 5 discusses acceptance tests, which allow the customer to know when the system works and to tell the programmers what needs to be done. It is the customer's responsibility to provide acceptance tests as part of each iteration, telling the programmers what must work and ensuring that changes to the system do not break things that already work.

Chapter 6 explains the process of estimating stories, and how long they will take to program so that customers know how much stories will cost in order to choose which ones should be completed. During the project, stories are estimated by comparing them to previously completed stories, although the time to implement a story depends not only on complexity but also how fast the team is working at that point in time. The estimation usually occurs by some neutral measure of time, such as a point system or "perfect engineering weeks." For stories that are unlike any story previously completed, the method of writing some sample code to make an estimation is preferred.

Discussion
The idea of user stories seems like a good idea for getting the customer to neatly lay out the features a system needs to have, although it may be confusing as it is unlike most methods. Acceptance tests could also be a useful feature, allowing both user and programmer to be sure that a particular aspect of the system is currently working despite any changes that may have occurred. While programmers generally find tests to be tedious and a waste of time, the customer's satisfaction should probably outweigh the programmer's speediness of programming. Besides, if the programmer is attempting to program as fast as possible, eliminating tests in order to do it, he is likely to waste more time fixing things that have been accidentally broken than would originally have been spent writing automated tests. Finally, the point system of estimating stories seems like it would be a pain. Instead, it would be nice to be able to say approximately how long the programming should take in days or weeks instead of assigning points that could be seen to have arbitrary meaning to different programmers.

Design of Future Things Ch 1

Reference Information
Title: Design of Future Things
Author: Don Norman
Publisher: Basic Books, May 2009

Summary
This chapter introduces the purpose of the book, describing examples of current and future technologies, and the problems and advantages of each. A couple examples are cars with auto-corrective steering and refrigerators that monitor food intake, providing suggestions where needed. The author argues that we need to change the way we interact with machines in order to take better advantage of them, while at the same time changing the machines to be less annoying and safer. Auto-corrective cars can be dangerous when the car acts unexpectedly, and the same goes for other technologies. The more powerful technology becomes, the more dangerous its failures in communication can become.

The author describes that the designer of a machine has the goal to create complete automation, eliminating the possibility for human error. Therefore, machines are often designed to automate many things, without considering the possibility of human error. So, when conflict or human error occurs, problems can arise. The intelligence of the machine rests with the intelligence of its designer.

The need for a symbiotic relationship is expressed, whereby machines and humans have a cooperative relationship that allows the enhancement of our lives. To accomplish this, there needs to be a more natural form of interaction that can take place subconsciously, allowing smooth communication between both human and machine. Machines will have to be able to make suggestions without controlling or annoyance, and provide enjoyment to its users. This interaction should be able to occur without significant training or skill.

HAL9000, a fictional sentient computer from 2001: A Space Odyssey.
Source: www.drucker.ca

Discussion
The author brings up some good points with his examples of technologies. In theory, many of these new automated machines can be very useful and time-saving; however, in practice, they just end up being annoying and a big waste of time. Humans enjoy the act of choice. With automation, the human is removed from the decision process, allowing no choice, as in the example of a GPS system that merely tells a person where to turn. What if they don't want to turn there? With cars that auto-correct speed or position within a lane, the auto-correction can prove dangerous rather than helpful if it takes the driver by surprise.

Because of these issues, future technology should take into account the necessity of human choice and control, and have systems designed accordingly. The need for seemless interaction between human and machine would be helpful with fixing this.

Extreme Programming Installed Ch 1-3

Reference Information

Title: Extreme Programming Installed

Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson

Publisher: Addison-Wesley Professional, October 2000

Summary

The first chapter, "Extreme Programming," discussed the basics of the extreme programming approach to project design. Extreme programming is described as "the discipline of software development with values of simplicity, communication, feedback, and courage." The chapter describes the role of various participants in the software development, including the customer (whose job is to choose what is needed to produce business value, builds stories, and specifies acceptance tests), the programmer (whose job is to estimate difficulty, design, test, program, and integrate the system), and the manager (whose job is to bring the customer and programmer together and to keep the process running smoothly). The rights of each participant are then spelled out, including such things as the right to produce quality work or to see progression.

The second chapter, "The Circle of Life," outlines the project flow process using Extreme Programming, in which the customer defines what has value and the programmers build it.

An example of the project life cycle. Source: Extreme Programming Installed.

Chapter three defines the role of the customer more definitively, arguing that the customer should be on-site full-time, in order to have more effective conversations with the programmers, leading to more satisfaction for the customer. If the customer cannot be present, someone should be there to represent them, they should be there for planning meetings, and code should be released frequently.

Discussion

Extreme Programming seems like a good idea for software development, making sure conditions are right to have high-quality, working products. For example, with paired programming, programmers have the chance to easily discuss problems with someone, and the two programmers can collaborate together to create better code than one person could have. However, this is highly inefficient. When put together, people are prone to distracting each other or conflicting with each other, leading to the result that paired programming would make programming take much longer than it would with the two people working individually. And while having an on-site customer would alleviate many problems and could lead to a highly useful product, it is very inconvenient. Most customers just want to hire someone to create a product, then leave them to it. The customer may have to lose out on valuable work time while being present on-site, making this idea a good one, but an impractical one.

Introduction

Name: Shena Hoffmann

What will you be doing after graduation? Going to graduate school to receive a Master's degree in Computer Science.

Computing interests: Artificial intelligence, information retrieval

Computing strengths: C++, Java

What was your favorite computer science project that you worked on? A Chinese Checkers game with an AI that could be played against. I liked it best because, while it was a pain to program, when it was all done we could sit and play it as a reward.

What was your least favorite? Systems programming for 313, because there was little documentation to help, and it never worked right.

What do you see as the top tech development of the last 5 years? Easily-accessible touch screens, because not only are they fun to play with, but they have so many useful possibilities as to what they could be used for.

Insight into management/coding styles: I don't like to manage, but I will do whatever work I'm assigned and have it done on time. I like to keep my programs nice and organized, with comments and appropriate tabbing.