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.
Monday, January 31, 2011
Thursday, January 27, 2011
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.
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.
Monday, January 24, 2011
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.
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.
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.
Thursday, January 20, 2011
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.
Subscribe to:
Comments (Atom)
