The Design of Future things: Chapter 2

The Design of Future things
Donald A. Norman

This Chapter goes into more depth regarding the relationship between man and machine.  When the first machines were created, interaction was purely one way with the human controlling the machine.  With the creation of computer and basic AI systems, machines are starting to have a voice of their own.  On a low level, appliances will notify you when they have finished their task.  On a higher level, some cars will pay attention to their driver and in case the driver is drowsy at the wheel or not paying attention, the car will beep or vibrate in order to wake the driver up or make him pay more attention to the road.  The car and driver relationship has come to replace horse and driver however, they still have many similarities.  In the future, there will be no need for driver's.  The driving of cars will become a hobby just like horse riding is now.  The day when people no longer need to drive cars will be the day when machines are smart enough to make informed decisions on a high enough level as humans. 

The sooner man can be removed from the machine, the safer they will probably be.  In most situations, wrecks are always due to driver error.  If cars drove themselves, and perhaps were on a network with all the other cars, death from car crashes most likely disappear.  There is always a chance of some possible error, however, machines are much less likely to make an error than humans.  It is my belief that once the technology is there, we should get rid of the human driver altogether.  People could then just be passengers in a car that drives itself.  As machines get smarter and smarter, humans cannot afford to get "dumber".  We should always have manual back up systems for machines.  Not to do so would be foolish.  Assuming that most of these automatic cars would use gps for routing, all it takes is a significant solar flare to take out over 50% of earth's satellites.  Then most of our gps systems would be worthless.  Humans cannot afford to lose common sense as machines and computers get smarter.

Extreme Programming installed: Chapters 1-3

Extreme Programming installed: Chapters 1-3
Ron Jeffries, Ann Anderson, and Chet Hendrickson

 Extreme programming, or XP for short, is a new way to develop software that focuses on improving the relationship between the customer and programmer.  XP has three main roles, the customer, the programmer, and the manager, each with their own responsibilities.  The customer is the stakeholder.  He or they decide what they want to be able to do with their program.  They determine the direction and the look of the project.  The programmers are responsible for meeting the customers specifications for the program as well as maintaining a steady flow of completed work.  The programmer needs to make sure he completes every user story the customer has given to him.  The managers responsibility is to make sure the programmers can accomplish their tasks.  They also handle all the planning regarding meetings and also handle any personnel issues.  The life cycle of an XP project is different than normal one.  The customer defines what he wants, the programmer determines the approximate cost of different implementations, the customer then chooses which he wants so that the programmer can get to work on it.  An XP project almost requires a customer to be on site, or at least on site most of the time.  This is because the interaction between the customer and the programmer is a lot closer.  The back in forth interaction between the two is what really sets agile programming apart.  XP wouldn't be taking advantage of this aspect if you didn't have a close relationship with your client.

I found these chapters really interesting because at my current job, we use agile development. Even though we don't use XP, the methods we use are extremely similar.  Agile methods are becoming more and more popular and that makes this book relevant.  Why is this? I could be a trend or maybe people just like the process better.  It's not that agile techniques are superior than traditional methods, they just have a lot of appeal for developers.  Agile methods do some things really well that the older methods lacked on.  However, agile techniques have their own issues.  It is so heavily dependent on communication that if there is a snag at all, it could put your program behind.  Also, agile methods use an estimation method to determine when the product will be ready, but this estimation can change greatly depending on how quick or slow the user stories can be completed.  So you can't say that agile is better than waterfall or vice versa, it really just depends on what suits your company better.  If agile allows you to complete projects on time with all the requirements met, why not use it.  If it fits your company and your employees, then agile will help your company succeed.

Design of Future Things: Chapter 1

Title: Design of Future Things
Author: Donald A. Norman


This Chapter focuses on the relationship between machines and humans and the positive and negative aspects based on the complexity of the interaction.  Communication between people and machines are completely different.  Between people, you can reason, discuss, and have a two way conversation.  Between a person and a machine, however, is quite different.  While it is true that communication can be two way, it is not considered dialog because it is composed of two monologues.  Communication between human's and machine's is constantly being researched and developed for various reasons.  Usually, it is for some convenience or possibly even to make something safer.  But as the complexity of the interaction increases, there can be some unforeseeable side effects.  An example given in the paper of a car that in which the cruise control is set and then forgot about.  The reason it was forgotten is because the car automatically speeds up and slows down based on traffic it sees in front of it.  Since the traffic was bad, the car was going slow but as soon as the passenger got of the highway and onto the access road, the car started to speed back up to the highway speed.  If the driver wasn't paying attention, this could have easily resulted in a wreck.  This happens because machines and computers are programmed to think logically.  They cannot reason and thus cannot account for all of the variables.  That is why researchers are looking into better ways for humans and machines to communicate.

This paper is extremely relevant to the future of the complexity of machines.  I have often thought about, from an ethics standpoint, the relationship between man and machine.  The liability aspect is an interesting to look at especially from persons standpoint.  Some of the luxury cars are now breaking for the driver if he is not paying attention.  However, if for some reason the system doesn't stop in time, it is still the driver's fault for rear ending the car in front of him.  I don't think I would ever willingly pay for some automated feature that didn't take the liability off of me as the driver.  I feel like I would be lulled into a false sense of security and therefore not pay as much attention to driving if i had all of these autonomous features in my vehicle.  There are other situations where automation is wonderful but just like all conveniences, there is an upside as well as a downside.

First blog

Hi, my name is Kyle Casey. I'm a senior computer science major at Texas A&M university.  After I graduate in May, I plan on going into consulting as a software developer.  I'm interested in many facets of computer science, mainly, web development, gaming, and database systems to name a few.  I believe i am strong in general coding practices as well as team leadership.  My favorite computer science project thus far was in my programming studio class when we got to design a racecar that we could drive or it could drive itself and we raced against are class mates.  The main reason this was my favorite was because my team just clicked.  My least favorite projects were the machine problems from 313.  Other than the pthread assignment, I just could not get interested in the material at all.  I think the biggest development within the computer science industry within the last 5 years is parallel computing.  By splitting up tasks and working them in parallel, you can exponentially increase performance. I'm not really picky about what style of coding I use as long as it is readable.  Nights are usually better for me since I work in the morning and have class during the day.