Book Reading #10: Extreme Programming Installed

Extreme Programming Installed
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley


Chapters 13-15: 


In these three chapters they were all mostly about testing and iterations with chapter fifteen diverting a little and talking about releasing code. The important thing that thirteen and fourteen pushed was the idea of writing tests for EVERYTHING you possibly can and making sure that for each few lines of code you have you have a test. Even if this means that the compilation and testing begin to take awhile you need to make sure you test each piece of your code and if the task takes too long then you need to reevaluate the test and try to make it more efficient. The newest and most interesting concept in these chapters was the idea of writing a test as though someone had already written the code, or programming by intention. This is the idea of figuring out what you need your code to display at the least, making it display this information and then working backwards to figure out the code and developing a test for it at the same time. The author even goes so far as to provide and example of him and a coworker working on a method in smalltalk programming by example and then writing the test for it to make sure it runs. The two do all the practices seen before of communication, documentation, naming and even pair programming. They don't really care about names at first and simply let things like names and variables happen organically and simply write what they intend for the code to do. The two go back and forth and as things don't make sense or begin to take too long they change it and make it very easy to understand. The fifteenth chapter talks about how while working you need to be saving and then releasing your code often. IT also talks about how conflicts can occur with releases so it is important to check with your colleagues to see who has what checked out and if there are some conflicts that arise to step through them, combine them, or simply archive both and then talk about it at your next stand up meeting. It is an important skill to learn for working in an Extreme programming group and will eventually help the writers to learn each others tendencies and work through problems.


I think these articles were very interesting but they left me with a lot of questions as to simpler ways to handle some of these things. The earlier part of the book talks so much about generating clear user stories and that each person needs to sign up for them and what not but when we get to this chapter it as if some of these practices are not quite applicable. The pair programming part of their work was interesting but it did not seem like the two were stopping each other when mistakes were made or when something didn't make sense. Perhaps it was that they both thought it worked at the time and then decided later it did not but they had to backtrack quite a bit and after a little while the example became muddled. I guess personally it also didn't help that they were programming in smalltalk and I have never used it before so some of the syntax was foreign to me and I didn't take the time to look it up. I also am really confused about releasing your code often and how they say to handle conflicts. If you and another coworker both finish early and end up working on another item and find you've both checked it out (somehow) why wouldn't you simply go to the other person and say "hey I did this what did you do?" and see whose solution works better and whose is easier to test. Maybe this was discussed and is not part of EP but it seems like a much simpler solution than trying to guess and see whose is correct. I do like the idea of coding by tests as just having a test may stop you from making a mistake or making the code too complicated.

Book Reading #9: Design of Future Things

Design of Future Things
Donald A. Norman
Designed and Edited by Donald A. Norman


Chapter 5: The Role of Automation


Norman in this chapter again starts with one of his favorite examples of design of future things and talks about the smart home. He talks about a test one that researchers have built and about how the inhabitants who live in it take awhile to get used to the house just as much as the house takes awhile to learn its inhabitants routines. It is able to adjust the temperature and shut off the lights and he even talks about how if intelligence is not built into the design that the house could potentially shut off the light in the bathroom while a person is still using it. He talks about how these ideas essentially boil down to the idea of communication and the role that it plays with in the design of new machines and programs. He then moves to a more interesting point which is, is it possible to send messages to the house or in some way program the house to help a family increase its communication. If this system were possible it would allow for this transition of communication and possibly help the family to learn to use computers to aide in the process. He gives the idea of a central panel that would sit in the kitchen. The panel would have a few ways to communicate to it, by text, by writing on it, and by programing your schedule and then sending it to the device. The device would show each users activities for that day and then if someones plans changed they would be able to show that and others could respond. The example given was that one of the family members needed to stay later at football practice and would need someone to pick him up. He sent a text to the tablet and then someone at home saw it and wrote on the screen that it was handled. Norman claims that the beauty of this device is that it is not giving the family a way to communicate but augmenting the way they already communicate and doing it in a practical way that is easy to incorporate into their lifestyle. He says that new designs should keep this in mind augmenting the users capabilities not trying to change them.

I think this article is interesting but I do have to say I am getting rather bored with Norman talking about the same ideas over and over. We have seen this idea of the smart home a few times in the book and he keeps referring back to it giving more and more details about it. I think that if he wanted to write a whole chapter about the house and then just refer back to it "remember the smart house chapter" that would be fine but each chapter I feel like I am relearning what he wants me to know about the smart house. The other big thing that he talks about is interesting how a fridge is a centralized communication device and that families use it in different ways. I also like the idea of the tablet that is able to take messages from many different sources and then the entire family can respond in some meaningful way. The example he gave was good but I question how often someone would check it. If I am sitting at home watching TV or working on my computer I might not go to the kitchen and check the tablet for a period of hours. If I had a family member who was stranded at football practice I might not see the message and then never think to go pick them up. More over, if the device would inform me when someone added a message to the board by emailing me or texting me then that could be a really neat way to communicate. Essentially the board is acting like a mail list and sends it to every ones phones and emails so that someone in the family can then respond. I also wonder if there is some kind of consideration for people who try to send a response at the same time or if two people respond to the same message posting. Would the system inform the users? Anyway the idea was very good and did help but there might be other practical implications that could be tied to it to make it even better.

Book Reading #8: Extreme Programming Installed

Extreme Programming Installed
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley

Chapters 10-12:

In these chapters we look at three very important, and now, practical, parts of the EPI guidelines which are: Quick Design Sessions, Programing and Pair Programming. Quick design sessions were the first to be discussed and were rather glossed over. They said that if anything these should be short 10 minute meetings on what needs to be done as well as a learning and catchup process for all the programmers to be able to understand where the project is headed and what their individual code is going to be incorporated into. They said that most of the learning in these will take place in the first three to four minutes then the planning is done in the remainder. The second issue they talked about is actually writing code; programming. They talk about the idea of starting by getting a simple piece of code into the machine and then testing it. The basic idea is that you want to write things that are as simple as possible and you want to make sure you use code that you have used for years. Everyone remembers how to write things such as adding up a list of numbers so try to make each item you work on feel that way and be designed similar to this very basic program. It would then make it very easy for you to go back later and change it if you found a faster way to do it that possibly used less cycles. Essentially they think that you need to keep four rules in your mind while programming: 1. Run all the tests 2. Express all ideas you need to express 3. No duplicate code 4. Minimum number of cases and methods. They then talk about a number of other techniques that are all very good to practice. Refactoring- the process of improving codes structure while keeping its performance, whether this is changing the way the code calls an object or adjusting the spacing and notes. Continuous integration- where programmers should be constantly putting everyone's code together and making sure it compiles in a reasonable amount of time. Coding Standards- make sure the code communicates and clearly as possible and maintains the standard that you want to uphold. These can be things as simple as indentation and as complex as naming, capitalization and commenting. Essentially, you want all the code to look as if it was written by one person when really it is a group of people who all have the same set of standards. To continue with this, they then talk about pair programming which is when people work in sets of two or three and make sure that both people are engaged in the code writing to help reduce mistakes and make sure that the idea makes sense to multiple people before testing occurs. Essentially the two work as a pair, one drives (does all the typing) and the other is checking the code as well as discussing ideas and making sure that the driving isn't making mistakes. When the driver does mess up the two switch or if the driver is less confident they stop, fix the issue and make sure to slow down to avoid the mistake again. It is a process that takes awhile for some, but eventually it becomes common place for workers to make their own pairs and take interest in others coding practices.

Pair programming is actually one of the things I wish companies would practice more. It seems like companies devalue this because it assumes that two people working on the same piece of code would somehow slow production when really a lot of times people end up asking others for help and the two of them end of getting both peoples work done in the same manner. I also really like the ideas of the coding practice that were discussed because they establish the idea of good object oriented programming which makes it much easier for someone to come along later and update your system without having to completely understand how it works or what every line of code does. It also does help to reduce the number of duplicated lines as you might be calling the same method a few times and it helps to write it once and then be able to just use it the rest of the time you write the program. This also does enable the user to break the program into smaller tasks and write simpler pieces of code rather than having to make long complicated methods in the main. Many of the commonly used languages today are very good about being able to integrate methods easily into a program and make accessing them quite easy. C++ even goes so far as to allow the user to access individual pointers that allow the user to touch the memory where the action will be set directly. I think the idea of quick design sessions are good but there was less than a page on them and they didn't entirely explain what you are supposed to get out of them other than more clearly defining parts of the program one of the programmers doesn't understand. The other thing that I dislike about all three of these chapters is while these might be doable in the business world, these are very hard to do in undergraduate academia, when each member of your group has 15 hours of class to take and 6-10 blogs to write per week, sometimes this system could just be more work than it actually would help your group.

Book Reading #7: Design of Future Things

Design of Future Things
Donald A. Norman
Designed and Edited by Donald A. Norman

Chapter 4: Servants of Our Machines

In this chapter Norman discusses the idea of what would happen if we became slaves to our machines, or have we already? He starts by giving a big example of how the user of a self correcting care was once caught in a street circle for nearly fourteen hours because the self correcting mechanism on his car kept detecting other cars nearby and then would adjust to help him to avoid them. After consulting with manufacturers, auto dealers, and even government officials who are supposed to be monitoring this kind of thing the only thing he was able to get out of them is that the automobile is clearly not supposed to act that way and was built so that the driver would be able to overtake the mechanism quite easily.  He then leads this into the idea of are we simply slaves of the tools we have developed. He claims that we would not be able to function and do many of the things we do everyday without the assistance of computers and other machines and essentially just as we are able to program a machine it is quite able to program us. He discusses, among his standard ideas of kitchens, cars, and other gadgets, the idea of a car that communicates with all other cars on the road. These vehicles would not only know where their destination was but also would tell other cars and be able to plan routes and organizational patterns very quickly so that they can get to the destination efficiently. He then took it further and talked about how if the car was able to communication all its information why would it not be a good witness for a trial and gives an example of a car being called to testify on a witness stand. He talks in the middle of the chapter about how these devices are being fed money and that there is a lot of research and much of it comes out at conferences. However he continues with the idea of the self-driving cars in the end of the chapter talking about how these would be practically programed. How would these cars drive themselves? One way he suggests is similar to animals who organize themselves into swarms and other groups cars might be able to imitate this behavior communicating their purpose in the group and then joining as a part of it. He also suggested that cars might form platoons and have a line of cars who are all going to the same place so that they would be able to plan a route together and then only have to communicate how many are in the platoon. He ends the chapter on almost a warning naming the dangers of what could come about and even defined the idea of overautomation. He gives some funny examples such as when people too much trust their GPS and wind up in a lake.

I think the most interesting part of this chapter is that he actually gives us a practical example of what something like this would look like. The idea that we would have to come up with some kind of scheme to organize cars on the road and what that scheme could look like is inherently interesting and the idea that we would take the queue from nature as far as forming groups is thought provoking. I seem to hearken back to Minority Report when I think about this where a very complex system of cars is established and people don't own cars they simply request one, it arrives, they tell it where to go and then its off. There is enough of them that a single person can request one and no one has to drive at all. The movie doesn't get into a lot of detail but it does have these notions of the cars being organized and being able to communicate where they want to go and figure out how to make everyone fit and get to their destination. Maybe it is my natural tendency to want to organize things but it seems to me, that organizational systems where the scheme is "just be in a group" is a bad idea. I think the platoon option sounds more concrete where if cars detect that they need to go somewhere they form a group and then they only need to pass their information and how many cars, this would also help to reduce traffic in the giant ad-hoc network that the cars would be creating. As I have learned this kind of study would not be a computer or technology issue more than it would be a wireless networking issue, of which, we have very little study in and only barely understand what all is capable. I think this chapter was very interesting and for the most part a lot of the ideas actually seemed rather practical. I don't want to go so far as to say they will happen soon but if we had the money and the people we would be looking at it not too far from now.

Book Reading #6 Extreme Programming Installed

Extreme Programming Installed
Ron Jefferies, Ann Anderson, Chet Hendrickson
Addison-Wesley


Chapters 7-9:

In this set of chapters the author discusses three main issues: small releases, customer defined releases, and iteration planning. The section on small releases didn't really cover much except that as a customer you are allowed to get small releases and see your program working through the whole process and as a programmer you have the right to release small packages to make sure that you get work done on time. The chapter then just goes into a bunch of various examples from when you have a simple situation to a more complex one in which the programmers need to make sure that they have clearly defined stories and make sure that they divide the tasks properly. The next chapter talks about how the group of programmers need to go about planning their releases and making sure that they meet the needs of the customer. This goes beyond just having a good time line and making sure you meet it for your customer but also that you don't over or under-load any programmer and make sure that the program gets out as soon as possible. Essentially this comes down to two main things: first, you need to make sure you write your stories clearly and then practice at comparing stories and seeing if you can accurately determine how long they are going to take. Second, you need to make sure that you get the correct amount of work done each week to make sure that you will release by the date your customer needs the software. These ideas both carry backwards to the idea of iteration estimates and then transition into the ninth chapter which is iteration planning. Iteration planning is the idea of making sure that you arrange all of your stories in such a manner that each programmer is completing the same amount of work each week up until the release date. There are a few different methods to do this but essentially they all come down to the same idea. 1. You plan your user stories 2. You brainstorm engineering tasks 3. you sign up for stories and get to work. If you are a newer programmer you might want to make sure that you get first choice at the items that you feel comfortable doing and then leave whatever is left to the more experienced programmers. As you become more comfortable doing this, you will find what you are able to do in a certain amount of time more accurately. The end of the chapter gives some ideas of different scenarios that might happen when doing this.

This set of chapters for me was actually new information. I think the best part of this is how closely linked chapters either and nine are and how the author suggests that programmers handle them. It also encourages an idea that I love which is make sure everyone is working on the tasks that they want to and not tasks that are assigned. It also allows for newer programmers to make sure that they get the easier tasks and not overload themselves. The only issue that I have with this kind of method is what might take a week for a newer programmer might only take a day or two for a more experienced one. I guess this goes along with the idea of knowing how long things took in the past and then relating them to the situation. It might also help to break chunks of tasks up into weeks. If a newer programmer thinks he can only handle one task that is rated a .5 then someone else might need to work a little extra to help him/her get going. The best thing that I like about these chapters is the amount of freedom that the author gives the group. A LOT of places in these chapters the author reminds us that there is no correct way to do these and simply suggests a good idea and then gives a solid example of how it works. It seems like so much of this method is very rigid and if you do it a different way it might not work out as to how the author sees you handling the situation. Granted all these ideas are really good it is nice to know that if you want to do something slightly different then there is another way and this book isn't the gospel. These techniques are quite awesome none the less and I really do hope companies use these more and more as they prove their worth.

Book Reading #5 Design of Future Things

Design of Future Things
Donald A. Norman
Designed and Edited by Donald A. Norman

Chapter 3: Natural Interaction

This chapter the author starts by talking about natural interactions of machines and humans. He claims that because we get so many signals from various devices that eventually it could be possible that we all get way too much stimulus and that eventually we will just have a large cacophony of sounds controlling us at every turn. He says, however, that the sounds need to be informative and distinct and let us know what the real problem is, he uses the tea kettle as a perfect example of this. He then talks about how in some cases different indicative noises can mean a level of comport for the user, letting them know that something is working correctly or is there. He speaks of how when he goes into a lab the different noises let one know that everything is in working order and may be seen as a form of normal rather than an indication that something is changing. He then talks about how these ideas can play into different everyday objects that we use, and sometimes people come up with novel ways to fix or use them. He claims that in the past these were called hacks but now we can call them affordances. He explains how these different kinds of affordances can be used in future design and let us know more precisely when something is being used correctly or when there is something wrong with its design. He then recalls back to the idea that there is an inherent problem of communication between the two: man and machine. The two cannot communicate in quite the same way and that raises the whole new set of problems. He then ties this back to the horse and rider design where the two have a common sense of a few different views of information and the communication between the two is a behavioral process that is at first learned but then eventually becomes second nature between the two. He then ends the chapter by discussing safety and how this entire study can relate to communication of warning messages and how if warning messages were displayed and written in a natural way and if the device was made in a way that humans wouldn't misuse it then there would be less issues. He ends as he has in all the other chapters by discussing ideas of the human-machine hybrid.

I think this chapter while interesting did talk about some points that were rather interesting. If you think about it there are sounds traveling all around us all the time, some to let you know something is on, some off, some to know they're working etc. However it does seem that in all this noise we sometimes still seem to miss various things, which is ironic because it probably was just drowned out by another noise. I think the most interesting thing is that despite all this I find myself just wanting some quiet and sometimes that's really hard to do with my dryer going off, my ac turning on and my roommates listening to music. In fact it seems like sometimes people spend just as much money to make things quiet as they do to make them noisy in the first place. Maybe the idea of a future system where machines know more about what were thinking are a good idea, and the idea that we will have behavioral patterns that the machine will learn when we want to be informed and when we don't. It is interesting that we are reading this now because I was just reading an article about how people tend to receive the interruptions of texts better or worse based on the content and the time in which they are notified. The researcher was trying to figure out how to make these times better for the user without attaching electrodes to their brain. I do agree that I wouldn't want my phone monitoring my brain waves but it would be nice for it to know not to interrupt me during blog writing for class.