Mythical Man Month CH 18-19

Chapter 18 was just a short outline of what the originally published Mythical Man Month had.  It went through each chapter and mentioned some of the key points.  The final chapter is about why the second Mythical Man Month edition was published.  The author speaks about some of the key points that made the book popular and why he thinks it still applies.

These two chapters were not very informative.  The author seemed to drown himself in self congratulations while he simultaneously shoved his own work and achievement further down our throats.

Mythical Man Month CH 16-17

Chapter 16 talks about how to make the software design process better and about how there is no silver bullet to the troubles of the project.  It argues that one of the biggest problems is that many companies seek to build what is already built instead of buying it on the market when they should which would be faster and cheaper.  Chapter 17 revisits the paper and the idea that there is no magic bullet.  It in fact argues that there might as well be one.  Most of this chapter is spent rebutting specific arguments.

I wasn't a fan of these chapters.  The papers seemed pretty outdated.  The second chapter was really bad in that it was just a rebuttle of many arguments that had been previously made.  The problem is that I was never part of the initial discussion so I have little stake in the issue.

Mythical Man Month CH 13-15

Chapter 13 talks about debugging and how to produce programs that work.  It highlights different ways to go about debugging the system as a whole and its individual parts.  The next chapter talks about how to deal with schedule slippage and that if the team is able to get ahead then they will have some cushion in case of an emergency.  The final chapter of this excerpt focuses on how to write good documentation with the author "showing" the reader how to write good documentation.

The second chapter of the excerpt, chapter 14, was really weird to me because it seemed to contradict the rest of the book.  For the entire book the authors had argued for the reader to make tight schedules that have no cushion but in this chapter, they argue that the team should work really hard to form a cushion.  So the question is what do they want, a looser schedule with cushion or a tight schedule with a team that is dying trying to get ahead.

Mythical Man Month CH 10-12

Chapter 10 discusses different types of paperwork and attempts to affirm their validity and necessity.  The next chapter goes in direct opposition to the XP book and talks about being ready to throw one version away, labeled a lesson learning endeavor and to plan for change in the project.  Chapter 12 talks about the tools that programmers and programming projects have and the differences between community tools and individual tools that the programmers don't share.

I liked the discussion about the tools.  I have seen many senior programmers that have their own small utilities that help them immensely.  I feel that I do this myself to a degree as compared to freshmen computer science students.  The idea that the best tool is communication and that the individual tools hamper communication was an interesting one.

Mythical Man Month CH 7-9

Chapter 7, as with the previous chapter, focuses on communication within the team and how to achieve effective communication.  It focuses on the documentation styles and keeping them consistent as well as how to effectively hold meetings.  Chapter 8 aims to demonstrate why some time estimates fail.  The author reiterates the fact that there are external problems that keep developers from seeing a 100% efficiency such as sick time, meetings, paperwork and others.  The final chapter of this excerpt deals with what the author calls, space control and how to fit 10 pounds of potatoes in a 5 pound sack.  It is the process of controlling how big modules become so that the system is not too big or not too small.

I had never really thought in terms of space control.  I have been doing it for a long time just without any real inherent thought for what I was actually doing.  The points that the author made really seem to make sense.

Mythical Man Month CH 4-6

Chapter four of this book works to demonstrate the need for specific system architects separate from the implementers.  While the author argues that implementers may have good ideas, a dedicated architect should be the one in charge of fully designing the system.  Chapter five discusses what the author calls "the second system effect."  The second system effect, as described by the author is that the second system the architect designs will most likely be over designed to compensate for the problems he or she had on their first system.  The final chapter of the excerpt discusses proper methods of discussion between the managers and the architects.  The author notes many solutions such as documentation and meetings.

I liked the idea of a dedicated architect.  I would say an architecture team would be more appropriate though to help the architect better touch on the element of HCI.  In all fairness though the book was written before the HCI field had really taken off.

The Inmates are Running the Asylum CH 3-5

Chapter 3 focuses on how software development processes waste money.  The author argues that in a lot of software development there is no clear end defined.  This causes many projects to define their completion by the ship date.  When this happens, poor software is released which isn't used and fails miserably.  The next chapter discusses, in more detail, the authors notion of what he calls "The Dancing Bear."  The dancing bear is an analogy for software that accomplishes a task that people are so relieved to see accomplished, that they don't care how badly the software accomplishes it.  The final chapter of this excerpt details customer disloyalty and more appropriately, how to get it.  Cooper argues that customer disloyalty will ultimately bring any company down eventually and that this should be avoided at all costs.

The ideas around how software development can waste money seem very well thought out and I generally agree with Cooper on this.  From reading this book in CHI, I know that I often times do not agree with Cooper but in the third chapter I really think he hit it on the head.  The number of software products that seem doomed by their schedule and lack of planning is just astronomical.  It is a very unfortunate truth in the industry.

Extreme Programming CH 22-24

Chapter 22 deals with handling deficits.  These are problems found in an already released iteration of the program.  For most deficits, the book advocates fixing them in the next iteration, however, if a deficit is too extreme it may need to be fixed immediately at the expense of a story that was supposed to be worked on immediately.  The next chapter is simply a conclusion of what has been discussed previously in the book.  The final chapter of this excerpt deals with teams having trouble adopting the XP method and why some groups are more resistant to the changes that adopting the XP method would entail.  They mention things such as programmers being set in their way or managers that are very draconian.

The first chapter was the primary meat of this excerpt and therefore requires the most attention.  Handling problems is often overlooked in the planning but it is important to know how to address them.  I liked the idea of simply making them into a story.  This is what we would typically do when I worked at Cisco and it seemed to work very well.  The real problem would only occur when serious errors were found that required us to update previous iterations.  Doing this would throw the entire system out of whack and take another iteration to get things back on track.

Extreme Programming CH 19-21

Chapter 19 deals with directing a project and handling the stories as they come in.  Chapter 21 deals with tracking the iteration.  It suggests assigning a person to the role of tracker.  The tracker would go from programmer to programmer asking them how they are doing on their assigned tasks and how long they think they have left.  The final chapter of this excerpt is about steering the release.  The chapter deals with how the programmers can make sure they are reaching the minimum requirements for a release before they actually go to release.

All three chapters were about steering.  It seems like a pretty important aspect of a project but these chapters, like others before it, had somewhat of a no duh factor.  It seemed like a lot of what they talked about should have been pretty easy to come up with on your own.  I did like the idea of having a tracker though.  It seems like having a tracker other than your direct boss would be a lot less stressful.

The Inmates are Running the Asylum CH 1-2

The first chapter is spent making the obvious argument that everything now days is becoming a computer.  From an alarm clock, to a camera, to an airplane, to even a warship, Cooper argues that everything has been crossed with computers, therefore turning the original item into a computer itself.  The second chapter deals with cognitive friction and how computers have so much of it.  For example, Cooper uses the argument that a violin, while complex, is easily understood by looking at the device.  Computers on the other hand, have an array of buttons that may do something different based on what state the computer is in.

I read this book once in CHI and I still have the same thoughts.  While Cooper brings up some good points, most of his points seem fairly outdated.  Computers now days have become quite stable.  For example Windows 7 has never crashed on me.  This is very different from when the book was written and computers would crash regularly.  The same ideas of making software easier to use are getting pounded to death in this book and I have trouble differentiating this book from all the other books that preach for better software.

Mythical Month Month CH 1-3

Chapter 1 of "The Mythical Man Month," gives some insight into the problems faced by some development teams.  The primary point made here is that while small teams can be organized easily, for large systems the effort is much more advanced.  The second chapter attacks some fallacies in planning such as programmer optimism in how long a task will take, the idea of a man month not mapping to more work being done, and that testing will take much more time that typically alloted.  The third chapter focuses on how to organize small teams that will make up the larger system team.  The authors argue that one person can be in charge of a small team, therefore only the leader of the small team must be filled in to the larger idea instead of everyone on the project.

I liked the fallacies.  I find that I, myself, many times fall prey to the optimism fallacy in planning.  The small teams chapter seems like it really dated the book.  I found it interesting how much of an importance the author placed on the secretary.  I have worked at a few companies and I don't remember anything but the highest employees having a secretary.

Design of Future Things CH 6

This chapter focuses on communication with machines.  He starts the chapter by talking about the failed Apple Newton from the 80's.  He describes how the tablet's hand writing recognition scheme failed because it would provide input that the user could easily blame on the tablet and not on the user.  He pointed out that if the system had worked such as instead of recognizing "hand," it recognizes "nand," the user would be more apt to blame themselves for not putting the stem on the h high enough.  Norman then discusses mappings and representations of data.  He discusses how people interpret artificial data and how better representations could be made.

I really liked Norman's discussion regarding the Newton.  I had never thought of that.  Unfortunately it made me think completely opposite of his intention.  Norman wants designers to design systems that just work but a lazy designer could easily design a system that puts the flaws onto the user, meaning that if something does go wrong, the design would cause the user to think its their fault.  This could effectively get designers off the hook for designing good systems.

Extreme Programming CH 16-19

Chapter 16 is a big list of bullet points on how to approach extreme programming.  It highlights the point of not programming for tomorrow three times to truly drive home the point.  Chapter 17 is a very short chapter that deals with scheduling.  It reminds the reader to only schedule in hours or more and not minutes.  Chapter 18 is the only long chapter in this excerpt and it focuses on tracking the progress of the project.  The chapter has a large suite of example graphs that the developers can use to track their progress.

There isn't much analysis that can be done on these chapters.  The ideas presented were pretty clear cut and straight forward.  The bullet points were somewhat of a nice addition because they got the point across without being incredibly wordy.

Design of Future Things CH 5

Chapter five focuses on automation and augmentation.  Norman talks about how automation is generally a good thing even though it may take more work at a later point.  He argues, using his coffee maker, that while the cleaning is more laborious, due to automation, one can choose to clean the coffee maker at a more convenient time than in the morning when they had just woken up.  He discusses augmentation devices that would help augment the human intelligence.  The devices, such as the cooking helper, serve mostly to aid the user in tasks that they would have done with or without the technology.

This was definitely one of Norman's least crazy chapters.  He seemed to have a better hold on the material he was talking about in this chapter.  I liked the concept of the smart home that he mentioned but was a little confused when he said he wouldn't want to live there.  He is continuously talking about cars that will take over some of the driving for the driver, yet he wouldn't want to live in a house that might accidentally turn on the lights when you don't want it.  Doesn't really make sense to me.

Extreme Programming CH 13-15

Chapter 13 of this excerpt deals with unit tests and proper methods of writing them.  The authors give specific advice to problems such as when the programmer is dealing with an external database and when code is present that doesn't have any tests already written.  The next chapter is a raw transcript of a pair programming session between the authors and how they wrote the code and the unit test.  The final chapter in the excerpt discusses releasing changes, the process, and how to avoid or fix problems that might arise.

I like the unit testing chapter.  As I have mentioned before, I think unit testing is a great idea.  The second chapter seemed a little useless to me.  I thought it was really weird that they used Small talk and not a more popular language such as C++ that most programmers would at least be familiar with.  It was much harder to follow because of their choice in language.

Design of Future Things Ch 4

This chapter is primarily devoted to the exploration of AI and its future implications in our lives.  Norman starts the chapter out with a made up story of a man stuck in a traffic circle for 14 hours because his car wouldn't let him steer out of the circle.  He then goes on to communicate some of the possible dangers of our machines getting smarter and contemplates how smart we may want them to be.  He then explores the possibilities of using swarm behavior on cars.

The book is titled "The Design of Future Things," but after this chapter its clear to me that the book really should have been named "The Design of Future Cars as Don Norman Sees It.'  Norman's fascination with cars and their designs really takes away from the book.  All he ever talks about is cars and the design questions that needs to be answered while not giving an answer himself.  His arguments could be much stronger if he had something other than cars to talk about.

Extreme Programming Ch 10-12

The first chapter is a small two page chapter about having a short design meeting between the programmers after the user stories have been recorded.  The next chapter addresses the issues surrounding implementation.  The book argues that the team uses pair programming taking a test first implement later approach.  The book heavily insists that all programmers own all pieces of the code, therefore allowing them to make quick changes when the need arises.  The chapter also describes the importance of a consistent coding standard, due to the fact that everyone owns all pieces of the code.  The last chapter of the excerpt focuses on pair programming and the functionalities that the "driver" and "partner" bring when working together.

The one thing that I really like about XP is the test first implement later approach.  I have found that in every single one of my projects, if that approach had been taken, better code would have come out of it.  The only problem that I see with it is management's reluctance to implement it.  If a manager doesn't understand coding and he/she just sees programmers working on tests for a few days with no real product being made, he/she could easily conclude that the tests were not worth it.  Other than managements problem with it, the approach could really help.

Design of Future Things Ch 3

In the third chapter of "Design of Future Things," Norman is back at it again, complaining about cars and attempting to make them better at communicating with the driver.  He discusses a simulation that he visited where the car would communicate what the driver should be doing by moving the steering wheel towards and away from the driver.  He then discusses the idea that if things are perceived to be dangerous, then the actual danger is lower because the people operating in the environment will be more careful.  Normans idea is to simulate danger in a car to help make the car safer.  Finally Norman makes small references to something called a Cobot and the Segway.

This chapter was not very different from the last two that I read.  I have a problem with the fact that Norman continuously comes up with problems but fails to offer any realistic solutions.  He finds some of the hardest problems which would take decades to solve and doesn't even attempt to seem like he has thought of possible solutions.  Because of this the book, and especially this chapter, can come over very whiny.

Extreme Programming Installed CH 7-9

Chapter 7 starts the section talking about small releases and how to achieve them in a real life project.  Many programmers will argue that their project is all or nothing, and therefore they are unable to do small releases.  The book counters that there are always small pieces that can be released such as replacing parts in a legacy system.  Doing so gives the customer time to learn what they want.

Chapter 8 explains how the customer should define the release.  This chapter is focused on what roles the customer plays in the release planning and how they should push for smaller releases.  Chapter 9 focuses on how the stories should be written.  The customer should define the story and the programmers define the point values for the stories.

This excerpt was pretty dry and bland.  Not much new info was presented in this reading.  There was some expanding of earlier points, however, I don't feel like I really learned anything new.

Extreme Programming Installed Ch 4-6

Chapters four through six of Extreme Programming Installed fortunately did not have the no duh feeling that the first three chapters had.  Chapter four explained user stories and how to create them.  It went into detail what a user story was and provided some examples while stressing that larger stories be broken down.  Chapter five explained acceptance testing using a unit test framework and the benefits that it could provide.  Finally, chapter 6  described story estimation, the art of estimating how much time must be spent on each story.

I liked these chapters much more than the first three, especially chapter five, which addressed unit testing.  As a programmer myself I despise all forms of testing and as such, I find that testing is my weakest point.  The idea of unit testing all stories would be extremely beneficial and is actually a great idea but I question whether it would truly get done in a real world setting.  In the companies that I have interned at the focus is always on pushing products out the door as fast as possible and as such, there is very little time given to programmers to formulate a proper unit testing framework for the program.  If I controlled my own company I would most likely try to implement a unit test feature if I wasn't the one doing it though.  The benefits just seem too large to ignore.

Design of Future Things Ch 2

The second chapter of "Design of Future Things," focuses on artificial intelligence and its effects on technology.  Norman spends a considerable amount of time playing up the AI field and highlighting its achievements.  An even bigger chunk of time is spent on discussing the future of the field and the potential for growth in the specification.  He makes arguments based on hardware while he somewhat ignores the greater and more important problems faced by the algorithm designers.  By Normans argument, in 100 years AI should be better by a factor of around 1 million.

While I liked his approach and some of the arguments he made, Norman seems to have overstepped some of this technical knowledge in this chapter.  The field of AI is incredibly large and has more challenges ahead of them than they do solutions.  It seems like historically the AI field has failed to deliver more than they have succeed.

What really bothered me was that Norman failed to recognize search as a field of AI.  He lists a non search related aspect as the most important and successful field of AI however I find it hard to believe that the web search engines like Google or Yahoo are not the most successful and important part of AI.

Design of Future Things Ch 1

Design of Future Things
Don Norman

The first chapter of "The Design of Future Things," focuses heavily on the lack conversions between people and machines.  Using the GPS features in cars, Norman argues that machines are unable to effectively communicate with the user, and that developers don't provide good ways for users to communicate with the devices.  In telling the story of his friend, who doesn't use the GPS feature because he has no control over it, Norman hits home his argument and opens doors of new thought.

After reading "The Design of Everyday Things," and "Emotional Design," when I took CHI a couple semesters back, the style of this book was not very surprising and I can already see some of the recurring themes from the first two books I read.  For example it only took Norman around 15 pages to rail against the concept of human error.

I liked what Norman had to say about communication with machines and how its not really communication, more like a double monologue.  I hadn't really thought of that before.  It seems like a very under explored problem, as in what I have seen in the HCI field is a focus on the machine more naturally telling the user about its state and not the other way around.

I didn't like how wordy Norman is though. As in the other books, he goes on some very wordy rants that seem to just circle back on themselves multiple times though.

Extreme Programming Installed CH 1-3

Extreme Programming Installed
Ron Jefferies

The beginning of the book is pretty clear cut in explicitly defining roles and giving an introduction into the world of Extreme Programming or XP.  The first chapter clearly defines the three main roles recognized by XP; the customer, the programmer, and the project manager.  Using these definitions, the book begins to explain a high level project cycle going from the customer defining the value to the programmer building value and back around in one big infinite circle.  The third chapter outlines the details and benefits of having an on site customer.

The definition of XP seemed to have somewhat of a well yea duh factor.  From a logical persons point of view it only makes sense that "stories," which seem a lot like a big task list for the programmers, should be written out to form a good program and that the customer should have a big say in the formation of the user stories.

I did like the chapter about having a customer on sight.  The simple fact, however, is that this is typically very impractical for the customer and they will most likely want a cheaper final price due to their efforts but no major software company is going to take a hit on their earnings.  It seems like there is a better way to go about this such as a video chat program.  The examples the book gave were all for small questions that could be answered remotely.

Introduction

Name: Mike Chenault

After Graduation: Software Engineer at Cisco working on the CIUS

Interests: HCI, User focused solutions, higher level software design, mobile apps

Strengths: Java, Android, C++

Favorite Computer Science Project: Last semester I implemented the Number Jumbler game on Android.  I really enjoyed it because it presented a problem of representing the dice and their state in the virtual space in an easy to understand layout.  The math parser that evaluated a string containing a math function was also very rewarding to work with.

What was your least favorite: I really disliked working on the Chinese Checkers AI for CSCE 315.  While it was in Java and I typically like Java, that was what made it so difficult.  I used a min-max tree and ran a DFS on the tree and Java was not well suited to this task.  If the project had been in C++ it would have been more enjoyable.

Top tech development of past 5 years: I would argue that the smart phone explosion has been the top tech development.  Just as with the internet, smartphones are changing the entire technical world.  The possibilities are endless.  Few would argue that in the future the smart phone will replace our need for a wallet, acting as an id, credit card, debit card, and any other items carried in a wallet.

Management/Coding Style: I am typically a brute force programmer.  I'm not a big fan of doing nothing and I like to see something come of my code.  As far as a schedule, I don't really have a set time that I am better or worse.  I will often find myself pulling late night sessions and getting a ton of work done but thats the closest I come to a schedule.  If something needs doing I will just do it when I have time for it.