Book Reading #22: The Mythical Man Month

The Mythical Man Month
Dr. Brooks
Addison Wesley Longman Inc.

Chapters 16&17:

These chapters both focus on the same topic, and that is, there is no silver bullet in programming. Essentially it is the idea that once the software becomes a large uncontrollable beast that it cannot be stopped. We all want to be able to shoot the program with the silver bullet and be able to reduce its time and costs and just have it be dead and done with. To accomplish this, programmers need to realize that they need to look at design elements such as conformity, changeability, invisibility and conformity and make them play off each other equally. This also takes the cooperation of a team and making sure that each player on the team understands what needs to be done as well as where the project is going. The team needs to have a unified programming environment and cooperating standards of coding to accomplish the task. The team needs to also be able to set themselves up into stations, similar to the idea of the surgical team each person needs to have a job and they need to be able to do it at all times. This makes the group flow together and they allow the group to make lots of prototypes and develop in ways that are doable by the programmers but also comfortable to not make mistakes. The whole team needs to have clearly defined roles and each person needs to make sure they have a mentor or someone who they can fall back on in times of need. However, there is some things that can be done to a project that can help it immediately, without being the great "order of magnitude" jump that programmers are looking for. Ideas such as designing the interface with the customer in mind and doing things that the customer said they would like to see in the software is a pure bona-fied way to get more sales as you are adding features that the users said they would directly pay for. There is also the idea of having "interchangeable methods" that is, methods that only do actions with the information they are given and do not affect the program as a whole, this way if a method becomes hopeless or done then it can simply be removed or fixed later. They also talk about the idea of the brass bullet and will it do when you cant find a silver bullet? Can you simply fix a lot of small things and make the program into a working piece of software that maybe has a few flaws that are livable? This essentially comes down to the idea of reusing what you can and doing cost-benefit analysis of what needs to be done and what can be left for a later version or an upgrade. Essentially it is the idea that while you might not be able to do a single change that will improve your program ten fold, you can fix enough to make it good software, you just need to know where to look.

I like these paragraphs for the most part but there seems to be examples missing here. I get what they are saying and I understand the chapters but I don't see any examples or what kinds of situations you want to practically apply these. In most of the chapters there are lots of good examples and there are specific historical and personal cases of the author using these and it really feels like he defends his work and says WHY these techniques work. In this case, he presents these two conflicting viewpoints and then simply says "these are the cases, they work like this" and doesn't really back up his claims. I feel like even if he didn't want to be objective and say strait out "I support this side of the argument" and then write more about that one that would be fine but we don't even get that. It feels like we are trying to fit into a small pair of jeans and we know we can simply cut off the knees and be OK. Why not just simply give a basic example and say that's good enough, why try to make these chapters so overly involved with technical. In fact these are some of the longer chapters and they really don't say much that hasn't already been said in earlier chapters of the book. I think that the ideas are really good but if you used some of the techniques presented earlier in the book then you wouldn't even be in this situation. I liked these chapters but wanted more examples.

Book Reading #21: The Mythical Man Month

The Mythical Man Month
Dr. Brooks
Addison Wesley Longman Inc.

Chapters 13-15:


In these chapters we find out about some of the more technical aspects of design and why they are important to us as computer scientists. The first part is about the whole and its parts and how any man can write any program it is based on if you do it correctly. The chapter then almost goes into a brief overview of everything we read about in Xtreme Programming Installed such as bug proofing programs, testing all the parts, top down design and the like. It did not go into the specifics on how to do this but rather overviews of each of the parts and why they are important. The latter half of the chapter was almost completely about debugging from figuring out what component and system bugs are and how to handle them both, to figuring out test cases for the two and determining patterns on how to solve them to important aspects of design such as paying attention to one component at a time. There was a bit at the end about quantizing data that was confusing. The next chapter was about hatching catastrophe and the steps that need to be taken in order to prevent a large error in your programming. The interesting part of this is that the first solution presented is to make milestones and not millstones, that is, if something is taking too long it is likely that it is not being done correctly or is being designed in such a way that there is going to be a lot of bugs in the software. In general, software should be relatively simple and anyone should be able to recreate what you did if given the time and the people. Software that isn't properly designed will just make the lives of those who need to use it later harder and likely they will spend more time figuring out what was done rather than how to fix it. They also talk about how you cant brush problems under the rug and this usually results from the conflict of roles in the office place. They say that management needs to be willing to yank the rug out and find out what is going wrong with something if an issue surfaces. The last chapter talks mainly about documentation and why it is required and important for every program that you write. There is a list of 10 things that are given to tell why it is important and why it is needed for each program. The author also actually says that flow charts are a bit of a curse and can at times be misleading. He rather says that you should have code that is very self-documentable and this should make the process much easier on you and the people who will use your software later. In all the chapters covered some of the rather difficult parts of design and let the reader know some simple things on how to prevent them.

The chapters were actually rather interesting and what I find more interesting is despite the amount of information that was said it was a relatively quick read. I think my favorite part was about hatching a catastrophe as just the initial setup of a program or the way something is defined can set it up for failure. If one tries to make one large code segment that does a very complex operation that can only be seen by the person who wrote it then likely that design needs to be broken into smaller parts and those parts need to be tested. I am a large advocate of writing small tests and making sure that all work mostly because that is what I am going to be doing at my job at Halliburton later this year but also because I have written many programs in academia and I have never had sufficient time to write small iterations and tests that I know would have been beneficial to the programs success. This leads into the next part of the text which talked about documentation and I believe if I had time to write these small tests that I would likely be able to site my documentation really easily instead of, basically, having one person from the group do the dirty work and write the documentation on his/her own. I think that the part on the whole and its parts were good and it did talk about debugging which goes hand in hand with testing but I feel like this was more of a recap of the Agile stuff that we have all learned. It seemed like the same lecture over again, program in pairs, test to find bugs, make user stories, make them small and estimate their time etc. I feel like this might only be so because I have had A LOT of readings this semester and a few of them have been similar. Despite this this was really one of my favorite set of chapters and I can only hope that the next chapters will be as informative as these were.

Results for Week[9]

We are still testing a lot.

Here is essentially what we want the tests to be:

<video removed>


And here is the shirt in covert action:

and here is lab sillyness:

Book reading #20: The Mythical Man-Month

The Mythical Man-Month
Dr. Brooks
Addison Wesley Longman Inc.


Chapters 10-12:


In these chapters we find out about some of the more design aspects of computer science, namely the thinsg that happen before youe ver wrire andy code. Specifically it talks about items such as system design documents, system specs, how you should be willing to throw stuff away and the tools you can use to make these better. The first chapter talks about the hypothesis that comes with designing documents and the various features that they have. Specifically its talks about different kinds of documents for different products. Clearly based on what you are designing you need different kinds of specifications based on computer size, data, budget and other factors once we have considered all of these things can we decide what specs we need for the system and iron all the details out. One of the most important thing to remember is that the reason we do documents in the first place is to make sure that everyone is on the same page and that there is no excuse for what work is to be done. It gives everyone a way to make sure that everything is done and documented. The next chapter talks about one of the most useful tools in document design and that is the idea of being willing to throw one away. The author wants to make sure you remember that the only thing in the world that is consistent is inconsistency and you need to be ready to do things different than planned. This simply drives home the idea of make two and be willing to throw one away, or if you can't be willing to throw away your first one.The problem with this is that even if you adjust and make a really good document you sometimes each time you fix a bug you are simply taking two steps forward and one step back as fixing one bug could cause new ones to surface. There will never be a perfect document but there will be a program that will be acceptable for the average user and the best you can do is keep the documentation and try to improve on it. Chapter 12 talks about sharp tools and the things we can do to make documents better. One of these is making sure you have a target, and making sure that everything you do towards the project is in line with that goal. They then go into some good discussion on high level language and how interactive programming can make this process better and smoother. The worst thing that can happen is when someone goes off and sits in their cube and codes without any interaction, the product may work but it will not be the best it can.

These chapters were actually really helpful the different ideas that were presented in this chapter were actually really helpful and they are things I can see myself having to look at in a few months with a job coming up. Documents can be very important and the time spent into them is all to keep people on track. IF you want to get code written in any reaonable amoutn of time you need to have your group organized and make sure everyone is working on something different and that two people aren;t working on the same thing. IT also helps if you do have a plan that is quire felxable and that is probably my favoire thing about these chapters is the idea of being willing to throw one away. I think that this is important because it goes beyond just coding documents it also speaks to papers in school, memos, emails and a lot of other things that need to be written and need to be flexible in case things don't work out. We have all also heard of the cs joke the last bug and this chapter basically says that is indeed true. You even might try to fix a bug and make two more so it is a vicious cycle if not done correctly. I didn't quite get the chapter about tools and really think it needed more substance and more practical examples of these tools. I think the author did a good job of describing them but it didn't really get what they were supposed to do. I think that these chapters were rather informative and that some of the examples were really good but they were sparse in places. The most interesting thing about these is that the more chapters I read the better I am starting to understand where the book is going. The lessons are really starting to make sense and the material is very relevant to me.

Results for Week 8:

We got the whole system together!! Woo!

Project over!

J/k but we did get a working model:

I know the video isn't quite a minute but its pretty close.

Things to work on for next week:

More stable construction for futher user testing
Application integration with GeoTrooper
Testing on person with battery pack.
More tests of user feedback.

Book Reading #19: The Mythical Man-Month

The Mythical Man-Month
Dr. Brooks
Addison Wesley Longman Inc.


Chapters 7-9:

In these chapters we find out about more interesting designs and concepts in the world of computer science production. In these chapters we cover how distastes can happen looking at the Babel Tower case. We learn about taking actions and making a choice, and also how we, as compute scientists, try to fit ten pounds of stuff into a five pound bag. The Babel Tower case was a disaster and the strange thing was that they had all the technology that was needed to do it, they had adequate time and funding, they had a good design so what could have possibly gone wrong? Well, apparently there was a lot of communication breakdown that all eventually lead to the end result of having a twisted heap of stone and wire on the ground. Essentially there were too many people trying to hold too many jobs and not enough ideas about the project or changes or information was being passed among the workers on the Tower. In fact the boss was being handed a new list of changes each day and he and his team would spend hours trying to figure them out only to have them completely changed and redone the next week. They also have a story about an engineer who is pushed so much that he is unable to do his actual job of being the construction engineer and needs to be helped a little bit. Essentially even if you have a good project you need to be able to adequately show changes and make sure that all the people who are involved and looking at the high level are easily able to understand them. In chapter 8 we are told to learn how to call the shot, and this involved making sure you know what is going on and then being able to decide what you want to base your calling on. Four examples are given and each highlight a different way of gathering and displaying data with the end result being that they were able to assist the person in getting to a decision but the overall effect was in most cases the same, making the decision. Finally we look at constraints that computer scientists run into, specifically we look at cases where the computer scientist tries to do too much with too little. Essentially each system has a set of constraints and part of the job of the designer is to try to work with these constraints and make sure that everyone understands what they are and how the group wants to work around them. There are size constraints, resource constraints and even constraints on how different things can be represented. They key is to make sure that everyone understands them and then when a solution is devised that everyone sticks with the plan and no one tries to become an island. There a few situations discussed here but overall driving home the idea of not trying to do too much with your limited time.

I thought these chapters were interesting enough. I think the part I liked the most was the engineer who got a couch in his office, I want a couch to relax on. It does speak to the point of understanding your space and being able to communicate things effectively so that no one person is trying to do too much. I also think that it is interesting on how the author talked about a situation where all the constraints were satisfied and still the project went wrong despite all these things. It seemed like he was trying to speak to the notion of this project would have gone much better if someone had only used the techniques from the next chapter and really just made a decision and ten made everyone cooperate. I also believe that a lot of the things brought up in the Babel case were classing computer scientists thinking that something is going to work and not really having the evidence or experience to be 100% confident. This kind of leads into the third chapter (chapter 9) that talks about how we have a tendency to do too much. What I find the most interesting is how the author does talk a lot about how there can be too many features in something but doesn't really go into the idea that as computer scientists we are very into processes and sometimes we can spend so much time arguing about the process that we forget to actually figure out how to design the system. I think there are a million more topics I could go on about with this but I think these chapters simply made me understand a few basic things: 1. don't try to do too much to any given project, follow the KISS principal. 2. If you are faced with a decision, gets as much information as you can and then make a call. 3. finally, if you are making changes, make sure they're clear and concise and report them to all the people who need to know about them.

Report on Weeks 6-7

Got quite a bit done!

Looking at in class presentation!!

Accomplished:

Got concept of shirt completed, can be done with thread.
Got blue tooth working.
Testing power supply.
Tested shirt for shocks and user wear ability.
Updated Aurdrino to being listening for blue tooth.
Wrote simple android app to test.

Book Reading #18: The Inmates are Running the Asylum

The Inmates are Running the Asylum
Alan Cooper
Sams Publishing

Chapters 3-5:


In chapter three we look at the idea of deadlines and how they are managed. In fact we learn that deadlines can sometimes be the ultimate factor that can kill a program and that more programs have died because of going out too early than have for not finishing features or not having an interface completely fleshed out. Cooper really talks about what done should look like and the idea that shipping something late is not the end of the world. In fact he actually sometimes encourages this just to make sure that the program is not rejected and the idea that if a completing product turned out then even if you quickly release another version then people might not come back to your product or try it again. He also stresses the idea that if you have a feature that is not completed it is probably better to leave it out then hastily shove it into a program and have it messing up different things that people work on. In fact sometimes having too many features that are only slightly buggy can be a lot worse than not having the feature and the user requesting it and then releasing it in a later version. In this way it also seems like the company is listening to the user and building their product to better suit them. In chapter 4 Cooper talks about the rather humorous notion of the Dancing Bear, that is, technology that doesn't work no matter how many versions of it there is and who designs it. He gives the mother of all examples and talks about VCR's and how it was impossible to tell what they were doing and despite companies trying to make them better and easier to use they were still nearly impossible to navigate and lots of money was wasted on trying to find ones that were intuitive and practical. He expands these ideas to the idea of email and calendar software and how their simple features that were probably not even considered to be bad simply go overlooked and end up becoming dancing bears of the program. Last he talks about the idea of customer disloyalty and how a product or program becomes desirable to the masses. He references chapter three a lot and talks about how these kinds of plans and features carry over to the idea of desirability and how time to market plays an important role but also that comparison is equally important. Simply put, if you have a similar product that takes longer to market and is more expensive it doesn't matter that you have feature X most people will not switch or even try. Same thing with releases each needs to be good to prevent disloyalty.

This is quickly becoming one of my favorite books, while it is a little longer and in some cases the examples seem to go on for forever there is some really good knowledge and the ideas that are being pushed forward are very solid and I can really relate to them. The idea of the dancing bear is really very smart and the fact that this happens a lot with products is really something that computer scientists need to watch out for and prevent. It also seems like this book is doing a rather good job of supporting ideas that were talked about in the Extreme Programming book in that programming in groups and making sure you make stories that the user will understand as a way to design a product is important. I think also that the fact that he head on tells you that some things will be wasting money is a really good idea. Simply put, if you try to do too much and rush out a program it really is going to be wasting more money than letting the project go for a bit longer and then having a good release, or even scrapping the project and cutting your losses and then putting those people on a new project or on other project, both of which have costs but in the end might help save you money. The bets chapter here is the one about disloyalty, what it means and how it is gained through comparison and markets. It is the idea that you need to have a good product every time all the time and that if your product fails even once it could possibly cause disloyalty and make the product seem inferior. I think this is very true and similar to the movie The Social Network, while the movie was overall not *great* one of the big things Zuckerberg pushed was the idea that the site cannot go down, otherwise it will become an afterthought. I liked these chapters a lot and really don't think I will mind reading this book if the chapters continue in this manner.

Book Reading #17: The Mythical Man-Month

The Mythical Man-Month
Dr. Brooks
Addison Wesley Longman Inc.

Chapter 4-6:

 In these chapters we are exposed to more ideas about what happens with programming and how different kinds of phenomena can affect a program. The first one we look at is the idea of different political systems in program design. This is simply the idea that sometimes when a program is written there are some things that try to be improved and implemented but because of the aristocracy of program design conceptual integrity is pushed to the wayside and not really able to be maintained. In fact there are a lot of times that a program needs to be worked on more and there is a constant back and forth between the programmers and the program leaders, pointing fingers and one side saying that the other is doing them wrong. This leads us into what Brooks calls the second system effect which is the idea that the second time a program is written it sometimes needs to be improved and sometimes this doesn't happen because of the discipline of the team or the programmer. Simply put, the second time a program is written it doesn't need to be a rehashing of the first program using its based code and building on it, it can be a whole new idea and the best way to do this is by having a large amount of self-discipline while programming. These are practices that the programmer wants to watch but in some cases because of not following self-discipline these ideas can get out of control and the programmer will try to do too much and have the second version nor working nearly as well as the first. Again the programmer is encouraged to make the second version new and better but needs to be sure to keep it in the realm of doable and not overextend and try to do things that will not benefit the program and make it take longer to produce. Last is what Brooks calls "Passing the Word", that is, the idea of how a program is described from management to programmers and the various techniques that do and don't work. He discusses the difference between the manual, definitions, incorporation and various other means. He explored the use of multiple implementations, logs and product testing as ways to make sure that the program goes out. While each of these has strengths the programmer needs to remember what is important and be sure that he works with management and that each task is clear. Although each of these various ways to define and test a program have their merits, companies need to carefully evaluate each and if one fails not be afraid to try another.

This picture warrants an explanation. I took from him that bad managers can be snooty and high strung, kind of like the aristocrats pictured here.

These chapters were very interesting but in some cases lacked the information that I thought would be necessary to understand these. For example in the last chapter the author talks about formal definitions for three pages and really spills out what it means and how the various features work, but then only gives a paragraph on direct incorporation and almost challenges the reader to look up the rest of their own. I really felt that this would be something to consider but it was as if he was trying to push the ideas of doing manuals or definitions. Also the chapters on aristocracy seemed really informative and if I was a manager I would really want to understand the psychology between these groups then this is the kind of information I am looking for, however, it did seem like the two sides really bicker a lot and he just talks about the situation and really kind of brushes over solutions. I can tell that Dr. Brooks has a lot of experience and is really smart and his chapters are really interesting to read but sometimes I am wanting a practical example or a solution and he really just gives incite and not a lot on WHAT to do or HOW to do it. I would think knowing that he is writing this for computer scientists and knowing how into processes we are that he would think to give some examples and how he changed them even if the changes were on a case by case basis. The most interesting part of this was definitely the second system effect and the phenomena that surrounds it. That kind of information will really stick with me and he even gave a small example of how he insulted Microsoft but ultimately was able to make them a really good product. It was well done and I wished that he wrote all his chapters in that style and it is an idea that will definitely stick with me in my professional career.

Book Reading #16: Extreme Programming Installed

Book Reading #16: Extreme Programming Installed

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

Chapters 22-24:

In these chapters we effectively finish the book, only do find that there are extra bonus chapters that are simply supplements to the important foundations of the book. However before the book ends we do find out about one taboo in extreme programming and that is the idea of defects...or is it bugs....nope we are not allowed to say bugs! In fact the chapter stresses that we need to not call defects in our code bugs one because of the implication that it is a problem that is going to be persistent and two because it honestly scares the customers and we don't want to do that. There are many ways to handle these and of course the foremost among them is making tests for everything and making sure your tests work before adding your code to the program. Ironically enough this is where a lot of the major bu...I mean defects happen is in testing. However this is not to say that one should not test because testing is very important but you need to make sure to handle defects as they come and stay on top of them. The most important practice in extreme programming is having a plan and sticking to it and if you deviate from the plan there are multiple redundant checks to get you back on course. The conclusion of the book are actual testimonies of companies and groups who have used extreme programming and how much more they really enjoy it than their standard practices. Some groups have found a whole new way to run their business and deliver code thanks to extreme programming. They put a lot of emphasis and really reading the text and essentially making sure you follow the 8 basics of the system:

-On site Customers
-Small Releases
-Planning Based on Stories
-Programming Based on Metaphor
-Pair Programming
-Continuous Integration
-Testing
-Forty Hour Work Week

Keeping these and some other details in mind makes sure that the system effecitvely works and make sure that your team is going to get done what it needs to get done. Finally the last part of these chapters is a suppliment talking about stories and keeping to a track called "We'll try" it is the idea that every programmer has spoken these words and in some cases it can mean the end of the program before it even starts. In fact most people will give up on a program when they think that there is a task that they cannot estimate and this ultimately causes the program to fail. This is not the case and in fact some of these things really are as easy to implement as they make them sound like in the book. Sometimes it may be hard to get a start on them but ultimately they are fairly simple and they just need to be followed and practiced.

I think these chapters in the books were almost eye opening in that people think these kinds of things are rather difficult to do when really they are quite simple. I think the most interesting part of this was when they actually had testimonials of different groups talking about how they were able to implement these kinds of things and it completely turned their business around. Even more interesting was the supplement that was added where they covered the same ideas of making user stories and really fleshing them out and then estimating them and telling people that you shouldn't just try these you need to commit to them and really do them. It does seem that at time a new system can be daunting but after reading this book and really trying to understand what theses kinds of different methods do and what these techniques promote in a group I really cannot see doing a system any differently. It seems that all the system does is simply drive forward the idea of writing good code and making sure you deliver it on time and essentially isn't that what any programming company wants to do? I really think this is a very good system and some of these supplements seem like they are going to answer my questions about what kinds of techniques are used in estimating and how pair programming can really help productivity.

Book reading #15: The Inmates are Running the Asylum

The Inmates are Running the Asylum
Alan Cooper
Sams Publishing

Chapters 1&2:

In the first chapter we learn what the author thinks about computer scientists, and while not incorrect it is a bit of a revelation. That aside, he really does focus on a very important issue that computer scientists need to work on and that is the idea that when you have a computer embedded with something else, you still have A COMPUTER. Essentially, its the idea that despite the fact that you might have an AI or complex system that is able to make an informed decision when it boils down to it you still have a computer. He gives examples and shows that really when you peel back all the pain you really do just have a computer and not much more. He then does a rather nice job of transitioning this into the next chapter which is the idea of the big scare word in computer sceince, which is of course design. and how we are just now learning what design means and how to to it properly. In fact there are many, many teams that get together everyday to work on this concept and really dont turn out much than more advanced computers that can't do much more than anything that could before. He also talks about how because we are on the verge and really understand technology we are the best and the brightest and eventually it might be such that those who are considered extremely intelligent are those who are the most computer literate. He even goes so far as to talk about how computer literacy might be the new social norm and that we will form casts of who is and is not computer literate. It might be that technology is just a part of life but the way computers are going now and research is being done that is not an unreasonable claim.

I liked this book in these beginning chapters. His examples are good and I believe he puts in pictures where necessary, some really help, some help a little less so. The most interesting thing about this is that similar to Norman he kind of covers the same basic ideas of design and talks about a few of the same ideas, however he does them in a much more interesting way. I don't know if it is him giving better examples or not dwelling on one thing for too long but it was much more enjoyable. He does give a lot of different examples and really makes the reader want to understand by standing the examples and less so by just accepting what he says as the truth. I think the part where he tried to define computer scientists and I think for the most part this is due to the nature of computers. Sometimes they really don't seem to follow any logic and do be better job of giving headaches as opposed to being a useful input device. Dr. Stroustrup always tells us that "Computers are dumb beasts" and the unfortunate thing is that they are more dumb than beast for the most part. Once programming becomes more natural and we as a society become better at programming them this is likely to change but until that time we are still quite stuck.

Book Reading #14: The Mythical Man-Month

The Mythical Man-Month
Dr. Brooks
Addison Wesley Longman Inc.

Chapter1-3:

In these chapters we learn about a few fundamental concepts of computer science. First is the idea of the tar pit. The simple idea that many computer scientists who thought they were the best in the world have found themselves skining into the tar and becoming unable to find their way out. They are discouraged when a duo of people in their garage have accomplished something similar to theirs without realizing the degree to which it might work. The idea is put out to not get to overwhelmed by what others are doing and to focus on what you are doign and not everyone else. It is also mentioned to bear in mind the real tiger is always better than a paper one. The next is the premise of the book which is the mythical man month. The idea that man power and months of time can simply be traded based on the number of people doing the task and the amount of actual time is spent working on the gross of the material. As we know this is not true and the author talks about how adding more people can sometimes simply slow down due to having to teach everyone the system, get them caught up, and then divide tasks even further. It might also be that some of these people do not have enough programming experience and can end up only contributing little. Simply put, the idea that you can trade men for months is a poor notion and that it needs to be balanced correctly in orther to work well. Lastly the idea of the surgical team. This is the idea that each team of a group needs to be about 10 people and needs to be setup in a way such that each member has a job on the team and can perform their job well. It all starts with a head surgeon and then you have the co-pilot, the expters, the secretaries, the brains, and so on. Each person does a little part for the team and make sure everything goes out. He doesn't go into great detail about each of the jobs but simply an overview of each and how the team should interact as a whole. He ends by talking about how this can be the best unit for breaking a 100 year job into a 1 year job.

Each of these chapters had something unique about them. It wasn't that the information was new or that it was a clever idea or scheme that was not considered it is the way in which he presented the material that made it very easy to read. The simple idea of comparing the overhead of programming to a tar pit or the idea of having each group work like a surgical team with each person performing a job and everyone working to get a single task done. It is one of the things that is almost directly applicable to computer science where we can say, "yes we can have this person do this and this person this etc..." each one doing a single job and worrying only about their end. That is not to say that if someone is slacking jobs cannot blend but for the most part but each person primarily should stick to theirs. The idea of the man-month was a bit more confusing but i think the premise is correct that having more people does not necessarily get you to finish something faster. You ahve to consider other ideas such as how to train the people and how to get them up to speed on the current system, it is not a cut and dry matter of throw more people at it until it works. All of them are great ideas and as I said were presented in such an easy to understand way that it made the reading enjoyable. When I am less tired I will probably enjoy this quite a bit more.

Book Reading #13: Extreme Programming Installed

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



Chapters 19-21:


In these chapters we find out all about steering a project and how it can drastically affect the outcome as well has having someone who helps with gathering results of a project and making sure everyone is on track. As you go through a project you want to be sure to have a tracker and make sure that the tracker is keeping tabs on everyone and where they are on their comitments. The person wants to be personable and easy to talk to and not be threatening or make people feel like they're not doing well. You want to do this regualarly to make sure that everyone is staying on track and steering the project when necessary. You also want to be sure to steer the iteration and the release in the same way. You want to be sure to get your most important stories done first and make sure that you have as many components of your release ready as possible. You might want to also be sure to contact the customer and inform him of any delays that you might have. The authors emphasize that understanding that each set back is the entire teams problem and not one persons problem is a big help here and making sure that each person is working towards the goal at all times is key. You as the manager want to make sure that everyone is on task and that you can help as many people at once as possible and steer the project.

I think that these chapters are only useful at all if you are the manager. IF you are an average working on the project it is a good idea to understand what is going on but you might not be interacting with people a whole lot. The biggest thing they cover here is the idea of steering and making sure that you get the things out that need to be out. The tracker is a good idea but in some groups this will be difficult for someone to do. You need to make sure you have the right kind of person and that the person is not intimidating anyone. You also need to be sure that if something isn't going as planned that you do make sure you keep the project on track and see what you can do to keep it going. If someone has gotten behind you might even have to do some programming yourself but this is all for the good of the team. I would definitely want to keep these things in mind if I ever manage a programming team and remember that it is an entire team practice and that no one is taking on more or less than anyone else.

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.

Book Reading #3 Design of Future Things

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

Chapter 2: The Psychology of People and Machines

In this chapter we get to see a lot of examples and discussions on the authors beliefs on possible interactions that machines and people would have and the psychological factors present in these interactions. Examples of planes, refrigerators, and even houses who interpret what their human owners want or need are given. He begins by talking about more recent examples of machines that think such as chess playing computers. He said that these were very primitive and that probably the most relevant example today is computer games that interact with and respond to the player. He then talks about how as technology for these kinds of things slowly progresses that we will begin to see the advent of what he calls the "machine-human hybrid". Essentially he breaks the differences in machines in humans down into three parts: visceral, behavioral and reflective. He gives examples of how each of these is present in different interactions of machines and humans and how in some places one or the other fails to display one of these. He again goes back to some of the examples in chapter one such as car and driver, horse and rider and talks about how each of these interactions displays each of these but there is a system of trade offs between them. He closes the chapter by talking bout how there are some subtleties to human speech that will be very hard for computers to recognize. For example, people who have known each other for many years often tend to "think alike" and when they see something they can refer to it without having to directly name the article. There are situations when humans understand what another human is conveying but this might be very hard for a machine to interpret. He points out that currently machines do this by the advent of handshaking. In fact machines talk to each other all the time, when you connect to any site on the internet or your CAPSTONE BLOG, two machines are talking to each other and confirming that you are getting to the correct place. He points out that the design of future things is going to be based largely on these communication issues and how designers begin to understand them and work to correct them.

I think these ideas are very good and very solid but some of his ways of presenting these ideas about the psychological interactions of car and driver and horse and rider are very boring and don't make a lot of sense in the spirit of HCI. It seemed that he was hammering home his own examples more and trying to make them fit when there might have been a better way to present the information. I think the most clever part of the chapter is his stories where the machines are personified and actually assigned emotions. This is not because this is how I see machines but because with advancement of technology this is what some people actually want them to do. Another item I did like was the discussion of the machine-human hybrid. The idea that machines and humans could work in harmony and your house and computer and other devices in your life could help you stay healthy and live easier is a good idea. If I had a fridge that could help me track my calorie count by talking to it I would buy one in a heartbeat and then I'd ask it to recommend something for dinner based on my calorie count for the day. These kinds of things would be useful though he does say ideas such as what if you want to make Easter eggs and cannot have eggs this week etc. The end of the chapter when he talked about handshaking and communication of devices was almost like a review of UNIX. It wasn't that he was wrong it was just dry for me due to my experiences in my UNIX class. I am curious to read on in the book and I am hoping for more specific examples and research that people have done and products they've made.

Book Reading #4 Extreme Programming Installed

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

Chapters 4-6:

Chapters four, five and six covered user stories, acceptance tests, and story estimation respectively. These principals covered were more ideas of how each of the steps in the design process should go. In four we looked at user stories and how the team should handle them. There was a large emphasis on the number of stories that each team should have and how to properly write them on index cards and then tear up ones that you do not want anymore. There was also a large emphasis on making sure each card is short and only contains one idea, if at any time a programmer is unsure of how long an idea will take to put into action it is probably too long and needs to be split into two stories. This also led into how the programmers should be comfortable with ripping up index cards as many were going to be used in the entire process. The next chapter was very brief but did talk about acceptance testing. This is basically the idea that the customer is allowed to see the program in working order at many different times throughout the process. The programmers should have a working version of the program each week for the customer to see and be able to talk about what they finished in the last week as well as what they are going to do this week. It was also pointed out that this step in the process is important so the user is able to change what the programmers did if s/he so chooses. Lastly the process of story estimation was covered, whereby the programmers rate with a number how many weeks they think it will take. Typical ranges covered were .5 - 4 and if anything was going to take longer than 3-4 it was discussed that it should, again, be broken into two stories instead of one. The latter half of the chapter then gave examples of some user stories and time estimates.

Again, for me, a lot of this was a review of Agile as we learned in class. Some of these ideas are very solid and I do like they way that they are done. I think the most interesting part of this is the way that they do user stories and estimations as it is much easier to teach than the way that it was presented to us. I like that each programmer gets their own stack of cards and that bad ideas are literally thrown out and that stories that are too long are literally broken into two different stories. I also like the way they decide length of projects and how there is a grounded system for assigning points. The way we did it we assigned arbitrary values to each story letting the SCRUM master know how long we think the story would take then we discussed ideas. In the way that was presented in the book they had a grounding for how long to make each story (one, two three, or half a week) and they were able to draw upon past experiences to compare stories and determine how much time a programmer was going to need. The chapter on acceptance testing was almost too short. While it did hit some good points about how the acceptance tests enable the user to make good decisions and change ideas it didn't cover much more and left me wanting to know a little bit more about them. 

Book Reading #4 Extreme Programming Installed

 
Chapters 4-6:


Chapters four, five and six covered user stories, acceptance tests, and story estimation respectively. These principals covered were more ideas of how each of the steps in the design process should go. In four we looked at user stories and how the team should handle them. There was a large emphasis on the number of stories that each team should have and how to properly write them on index cards and then tear up ones that you do not want anymore. There was also a large emphasis on making sure each card is short and only contains one idea, if at any time a programmer is unsure of how long an idea will take to put into action it is probably too long and needs to be split into two stories. This also led into how the programmers should be comfortable with ripping up index cards as many were going to be used in the entire process. The next chapter was very brief but did talk about acceptance testing. This is basically the idea that the customer is allowed to see the program in working order at many different times throughout the process. The programmers should have a working version of the program each week for the customer to see and be able to talk about what they finished in the last week as well as what they are going to do this week. It was also pointed out that this step in the process is important so the user is able to change what the programmers did if s/he so chooses. Lastly the process of story estimation was covered, whereby the programmers rate with a number how many weeks they think it will take. Typical ranges covered were .5 - 4 and if anything was going to take longer than 3-4 it was discussed that it should, again, be broken into two stories instead of one. The latter half of the chapter then gave examples of some user stories and time estimates.


Again, for me, a lot of this was a review of Agile as we learned in class. Some of these ideas are very solid and I do like they way that they are done. I think the most interesting part of this is the way that they do user stories and estimations as it is much easier to teach than the way that it was presented to us. I like that each programmer gets their own stack of cards and that bad ideas are literally thrown out and that stories that are too long are literally broken into two different stories. I also like the way they decide length of projects and how there is a grounded system for assigning points. The way we did it we assigned arbitrary values to each story letting the SCRUM master know how long we think the story would take then we discussed ideas. In the way that was presented in the book they had a grounding for how long to make each story (one, two three, or half a week) and they were able to draw upon past experiences to compare stories and determine how much time a programmer was going to need. The chapter on acceptance testing was almost too short. While it did hit some good points about how the acceptance tests enable the user to make good decisions and change ideas it didn't cover much more and left me wanting to know a little bit more about them. 

Book Reading #2 Extreme Programming Installed

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

Chapters 1-3:

The introductory chapters introduce us to the philosophy of extreme programming. It is broken down into three parts and each covers a different aspect they are: Customers, Programmers and Managers. Some responsibilities and attributes of being each are given and they are similar to the practices used in Agile. The authors then list the ideals of extreme programming and gives some insight to what each means in the sense of building a program. These are ideas such as how managers have the right to have a plan, change the plan, and get the most value out of every programming week. Programmer right s are ideas such as: the right to produce quality work, the right to ask for help, and the right to accept your responsibility and not have them assigned to you. The book then goes on to talk about the programming life cycle and how the relationship between the customer and the programmer works. Here we learn that while the customer wants results they need to be a part of the system to make sure they receive good, quality work and not try to set the programmer to strict deadlines and set high demands which will likely only get them poor work riddled with bugs. Finally the authors discus the importance of the role of the customer and how the customer should be there in each stage of development. They discuss ideas of how the customer is allowed to see and change each program iteration and needs to be there to answer questions in a clear and concise manner. The authors end with stories of how not having a customer present for even one simple question may slow development by nearly a week.

These chapters were not much new information for me, in many classes we have done agile and the system of extreme programming is very similar to this. Each of the roles of each person are very well defined and the authors provide good examples of when each of these is a factor and needs to be considered. I think the most interesting things were how the philosophies of this were much different than Agile, but I still got the same sense that the practices were intended to have the same overall effect. I have also talked to many companies about their view on Agile and they said some of the practices were very hard to implement and that they were only able to do so many of them. This makes me wonder if XP will be the same way and will be a good idea but not fully implementable by companies. I think however the one thing that XP does well that Agile does not cover is the importance of the customer in the entire process. It does seem like exchange of information and ideas would be much faster and easier with a customer present and they seem to be an important part of the development process.

Book Reading #1 Design of Future Things

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

Chapter 1: Cautious Cars and Cantankerous Kitchens: How Machines Take Control

The author talks about various technological advances and the new kinds of machines that are being invented to help our lives. He talks about ideas such as cars that help to correct steering, rooms that wake you up and greet you in the morning, kitchens that regulate and watch what you eat and various other computer based appliances. However he does not just present the good points, he also talks about their downfalls and how they are not intelligent siting friends and co workers whom he has discussed these ideas with. His main example to show this is a car navigation system. He argues that the car can only give advice and there is no communication with it. He leads this into a discussion of the idea of a symbiotic relationship with machines. He gives this arguments in terms of four examples: people and traditional tools, horse and rider, car and driver, and machine recommendation systems. His main argument is not that these do not work it is that because there is a lack of communication between the two there is only so much that the non-human can understand. In essence, because machines lack true intelligence it will be very hard to determine what all interactions that people will have with them and this can pose many problems in design of future, similar technologies. He ends by discussing other machines and how they are designed. His focus is that while it is easy to program logic into a machine to make it do a task it is much harder to see all of the possible uses and consequences of peoples actions. The main idea is the idea of a programed house, while it would be nice for the house to be able to sense stress and help calm you, what if you need to get up in the middle of the night and it greets you good morning? He claims that the difficulty is not the logic, but tying emotion to different decisions and having the machine sense what we want them to do.



I think this chapter despite going over some of the same arguments twice does being forward some very interesting issues. The main one that I liked was the idea that design and actual implementation/use are very different from one another. I have found that in many new creations that the way or purpose that people use them for is not the same as the original creators image. In fact this does not have to be seen as a bad thing, it can be seen as a good thing. The way that I see this is that (essentially) people are beta testing my product by exploring its capabilities and then commenting on how the design fails or succeeds. In fact, when a new product is developed, the best thing one could do is first give it to a very select group that will use the item constantly and then have them give feedback and comments on what people say about it. Something like the self-following luggage (mentioned in the chapter) is a good example of this as people would see it and then ask where they got it and other inquiries. If a conversation were to get started about it there could be very good questions raised "How do you know if the luggage gets stuck? How do you know if someone has grabbed it or knocked it over?" These could be taken into consideration and then reversely used as selling points for the product (Hey, we beta tested this and this is what happens if someone tries to take it *alarm*). The creation of any new product or new idea needs to have some study go into it the problem is when companies try to compete with one another and push out products without acceptable levels of testing and life-threatening consequences arise. In fact again I will agree with the author that new technologies need to be designed based on how the user is going to use them naturally and not how the company WANTS the user to act.

Intro Blog Post

Hi I am Derek Landini. After Graduation I will be working at Halliburton in Houston doing program development and testing for in-house technologies. My main interests in computing are HCI, JAVA, C# and GUI programming. My biggest strength is definitely doing graphics. My favorite project was building the AI car in programming studio and my least was doing the C++ database in the same class because of the size of the project. The best tech development is by far carbon nanotubes and anything built from them. The coding style I have come to like is agile, but I do not think that there needs to be a rigorous following of it.