The Design of Future things: Chapter 5

The Design of Future things
Donald A. Norman

In this chapter, Mr. Norman discusses automation and how the current trend for technology is heading that way.  Automation in itself is not all it is cut out to be.  We use automation to do tasks for us that we might consider menial or time consuming but at the same time, it spawns a whole other set of things for us to do.  Mr. Norman gives an example of how a coffee machine makes coffee automatically for us.  Even though it didn't take much effort to begin with, in the morning, we really don't want to do it.  So having the automation in this case helps us.  This automation creates some minor inconveniences.   After we have had the coffee made for us, we now have to empty the grounds, remove the filter, and clean the whole unit.  A group at Microsoft is also looking into automation but as more of a helper for humans and not a replacement.  This is currently being researched for use in smart homes.  These homes would help busy families with scheduling and planning during the week.

Automation has its benefits but I think it should be used to supplement human effort rather than replace it.  Technology may not always be there and we cannot afford to forget how to do things without technology.  That is why automation should supplement human effort that way we always still have some responsibility or task we can do.  I think the smart home idea is really cool especially for a busy family.  If it could be used to help find more time that families can spend together, it is definitely worth it. 

Extreme Programming installed: Chapters 13-15

Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson

These next three chapters cover unit tests, test driven programming, and how to handle release changes.  For unit tests, the programmer needs to be able to test every single class and method and that test needs to run 100 percent of the time.  We do this by writing code that tests each method or class within our current project code.  This can be quite overwhelming especially if you have a large project.  That is where the next chapter comes in.  Basically, in extreme programming, you want the tests to drive the coding.  Why write new code when your tests already tell you that the current  code can handle everything you need it to.  You should only write new code when one of your tests fails.  Also, XP is notorious for lack of planning.  They don't focus on how to do something, rather, on what they need to do.  This is called programming by intention.  Collective code ownership is very important to XP.  It allows things to get done faster and at a higher quality since programmers don't have to wait for permission.  At the same time, releasing changes becomes a lot more important.  There are three main steps that pair typically follows which are called local, release candidate, and released to the repository.

I have never really used any of these ideas too much at work but I know they are used on some of the larger projects.  I know that unit tests are important but sometimes i feel like they take more time than the actual coding process.  I think there needs to be a balance between how much testing as done and the actual coding.  If you focus on too much on one aspect or the other, you tend to treat the other with less focus.  That is why there needs to be a balance and the project lead should be responsible for that.

The Design of Future things: Chapter 4

The Design of Future things
Donald A. Norman

As machines become more and more complex, they run the risk of having severe side effects.  It all comes down to degrees of control.  It is always the unexpected consequences of technology that have the biggest consequences.  The bad usually make headlines.  Nearly every major technological tragedy was do to unforeseeable consequences. Some people complain that we are becoming slaves to machines and in many ways we are but people do not see it as slavery.  Machines make it easier for us to live and people usually aren't willing to give that up.  More and more, machines are heading towards full automation.  Imagine having cars that drive themselves or appliances that just know what to do based on what you put in or on them.  Overautomation can be a problem however.  In some situations, your really do need to have a human presence in a machine just to account for unexpected variables.  If machines are overautomated, people tend to get to relaxed because they assume that nothing is going to happen.  There really is a fine line between automation and overautomation.

I for one would like more automation in machines especially when on the road.  It would be much safer if we could take the human's out of control of vehicles.  I would wager that 99% of all accidents are human related.  If we take out that, car wrecks would be virtually non existent.  The only issue with humans being so dependent on machines is that we may not be prepared for life without them.  Emp's will pretty much render all machines useless now since almost every machine has a computer in it.  So if for some reason we weren't sent back to the stone age because all of our machines were disabled, humans might not have the skills necessary to survive.

Extreme Programming installed: Chapters 10-12

Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson

These next three chapter are fairly important for extreme programming to be successful.   They cover quick design sessions, programming/code quality, and pair programming.  Typically in XP, once the user stories are done, most people jump into test first programming.  If you are consistently running into situations where you have to have design sessions, it is possible that your user stories are to large.  On the rare occasion though, it can be useful to take about 10 to 15 minutes to sketch out a basic design structure.  This design meetings should never go over 30 minutes in length.  Programming in XP projects are done in pairs for production coding.  Your partner will probably change quite frequently based on what your are working on.  Each pair is given and task and is required to complete that coding assignment.  They can test its completeness through a unit test which tests every possible thing that can go wrong.  If the unit test returns 100, then the item is ready for production and deployment. Within XP, there is the idea of Collective Code ownership.  This basically means that all of the programmers are responsible for all the code.  If a programmer needs to modify an existing class to add some utility, he can do that without consulting the person who wrote the class initially.  This allows a programmer to create much quicker solutions and gets rid of the middle man when it comes to fixing problems or adding functionality.  Pair programming is another essential part to XP.  Having two people writing the code actually produces better code faster and you also have 2 people who understand it instead of 2 people who only understand half of it.  The pair should both be actively helping program even if you are not the driver.

XP does some things that most programmers would think would not actually help production.  The lack of design meetings is one of them.  Honestly, sometimes having an overall structure can be useful and should be done but most of the time, it usually isn't necessary.  The structure will usually define itself as the project goes along.  Programming and code quality are important for any programming type, not just XP.  It is important that the programming lead determine a coding style for the whole project.  Without it, you run the risk of writing code that your colleagues might have trouble interpreting.  I've never actually done pair programming but I think it would be really helpful.  Sometime I feel like I waste so much time looking things up that someone else probably already knows how to do.   It is also useful to help train some of your newer employees.  By having them help out a senior programmer, they gain valuable experience while also contributing to the project.

Extreme Programming installed: Chapters 7-9

Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson

 These three chapters cover small releases, customer defined release, and and iteration planning.  XP projects rely on quick releases.  The only way to do this is to make iterative small releases.  By doing this, the customer always has some kind of product with some kind of basic functionality.  By doing quick small releases, your customer is constantly giving you feedback on the direction on the project.  This allows you and the customer a greater level of understanding. The project will be on track and please the customer much faster.  In XP, the customer decides the release date based on how they assign the releases.  Sometimes the customer has a hard time creating user stories that are able to be done in small releases.  If this is the case, the customer needs to be there when the programmers are grading the user story on difficulty.  Stories cannot be rated in months so the customer really has to learn how to define user stories on a smaller scale.  This should get better as the project moves along.  Since the customer is making the user stories, he is also determining the release date of certain tasks.  This helps to define the priorities of the project.  This goes hand and hand with iteration planning.  The customer is responsible for determining what gets done each iteration.  So a programming team has a velocitry of 30 points.  In the planning meeting, the customer presents the user stories, the team brainstorms the tasks, and then each programmer picks a task.  Each of these tasks have a point value associated with them which in turn determines how much work the team will be doing this iteration.

These 3 chapter focus more on the practicing side of XP.  It defines what exactly goes on in the planning process fro each iteration.  Some people really like this part of XP while others really hate it.  It largely depends on the people in your programming team.  It takes a lot of self discipline in order to pick a task and then complete it before the end of the given period.  Sometimes teams run into issues when certain people are not pulling there weight.  I have actually run into this a couple times when certain people have not pulled their weight.  This usually forces someone to step up to the plate and take on extra work in order to keep the iterations on time.  It really isn't fair for that person and increases the overall stress associated with the project.

The Design of Future things: Chapter 3

The Design of Future things
Donald A. Norman

 This chapter focuses on natural interaction.  Most machines now days use one or many signals, either visual or auditory, to communicate back to humans. The amount of signals machines send to us now can at sometimes be overwhelming.  It is really easy to get mixed up on what machine is signaling as well. A washer and dryer of the same make often have the exact same auditory sounds in there control system. Yet it is still easy to figure out which one is signaling you due to natural sounds.  Why can't more of these natural sounds be incorporated into modern machinery.   One popular example of a natural interaction is a tea pot.  When the water starts to boil, the tea pot starts to whistle and thus provide a natural auditory feedback to notify the user that the water is boiling.  Some designers have even made it to where the tea pot makes a pleasant musical chord from the steam.  Natural interaction is something inventors should try to maintain in this modern age.  As the auto industry shifts to electric cars, vehicles are becoming more and more quiet.  This can be a big problem especially for blind people.  Since they rely heavily on sound, not being able to hear a car can be extremely dangerous.  Even for the driver, the lack of noise in the car takes away a part of the natural feedback cars use to give us.  Machines and users need to complement each other.  If they could do this, the interaction would be much more appealing to users and safer overall.

I think natural interaction is a nice thing because it allows communication on a deeper level.  Machines that have the ability to communicate with their users on deeper level will be infinitely more useful.  Having that natural interaction allows the person to understand their machine a lot better.  For example, world war II pilots use to be able to know exactly when their plane was going to stall just based on the whine from the engine.  That natural communication gives the pilot an increased sense of control over the airplane.  This is similar to how some mechanics can tell what is wrong with a car just by listening to it.  These auditory clues, however, are usually only detectable by extremely experienced people.  This kind of understanding should be pursued in today machines.  People are very good at understanding how to use machines or devices before they even know what they are.  It shouldn't be to hard to use this understanding to help facilitate natural interaction between people and machines.

Extreme Programming installed: Chapters 4-6

Extreme Programming Installed
Ron Jeffries, Ann Anderson, and Chet Hendrickson

User Stories, Acceptance tests, story estimation 
These three chapters focus on three really important aspects of extreme programming which are user stories, acceptance tests, and story estimation.  A user story is equivalent to a requirement for a program.  Basically, the customer specifies an example of a user interaction which is written on a card.  It is then the programmers job to make that example come to life in the program.  XP breaks down the entire program into various user stories so that the programmers can handle each individual task separately.   Acceptance tests are the specifics of each user story.  While the story gives an example of the usage, the acceptance test specifies what exactly the program needs to do.  In order for a story to be complete, it must satisfy its own acceptance test.  Story estimation is when the programmers try and put point value on each story to estimate the difficulty of that specific requirement.  Initially, it is usually not very accurate but as the project moves along, the programmers start to get a feel of how difficult the stories are going to be based on the stories they have already done.  Story estimation will help to give a time line to the customer with an estimation of the finish date.

 

 These features of extreme programming are some of my favorite.  Having an example of the interaction from the user story allows the programmer to mimic it without having near as much guess work.  From the other side, the customer can be extremely specific with the kind of interaction they want when they help approve the user story.  Having used this before, it really does help in the overall build of the program.  It seemed like the projects are a lot more organized and I feel like I always have a direction to go in.  I don't have to figure out what part of the program I need to work on next.  I simply just move onto the next user story.  Acceptance tests and story estimation go hand in hand with user stories. XP provides benefits to both the customer and the programmers that really isn't matched by other programming methods.