The Mythical Man-Month Ch 18 - 19

Summary

Chapter 18 – Propositions of The Mythical Man-Month: True or False? – This chapter is a summary of the entire book, chapter by chapter. It outlines the most important points from each chapter and what they mean.

Chapter 19 – The mythical Man-Month after 20 Years – This chapter discusses why the second edition of the book was made and what still remains unchanged and current from that version and what does not. The author explains how conceptual integrity is still central in both books. Also, he talks about how WIMP (Windows, Icons, Menus, Pointing interface) in his opinion will be obsolete in a generation. He also explains why the waterfall model is wrong and why we should not use it. At the end, he discusses the importance of a good team, what technology has achieved and its effect, and what he expects of the future.

Discussion

I really liked chapter 18 as it encompasses most of the important points discussed throughout the book. It is a good summary and it refreshed my memory on what I have learned throughout the semester. Chapter 19 was also very interesting as he goes back into the book and updates the reader on the things that are now outdated and the things that are still relevant. Some of the things he said, however, made some of the chapters seem pointless to read. In any case, it definitely doesn’t hurt to know all these things. It was a good book!

The Mythical Man-Month Ch 16 - 17

Summary

Chapter 16 – No Silver Bullet – Essence and Accident in Software Engineering – In this chapter the author divides the difficulties in software development between essence and accidents. Essence describe the difficulties inherent in the nature of software; while accidents describe those difficulties that today attend its production but that are not inherent. He explains that in the next decade there will be no major technological or managerial development that will improve our productivity by one order of magnitude. The chapter describes how little has been done over the years to improve how we carry on the essential tasks so even with all the technological advances our productive has not yet improved by an order of magnitude because they have only addressed the accidental part of the equation.

Chapter 17 – “No Silver Bullet” Refired – the chapter divides the essence into four subcategories: complexity, conformity, changeability, and invisibility. Complexity refers to how no two parts of software entities are alike and how they have a huge number of states. Moreover, as the size of the system increases, its parts increase exponentially, and you can’t abstract away the complexity. Conformity refers to the arbitrary sets of rules and changes software has to go through. Changeability refers to how software is constantly asked to change. Finally, invisibility refers to how software is invisible and unvisualizable in contrast to other more tangible things and this lack of visualization deprives the engineer from using the brain’s powerful visual skills.  In this chapter the author reflects on a paper he wrote ten years before and clarifies certain misunderstandings. At the end he quotes what someone wrote about his paper that summarizes what he wants to say: “Software development is a conceptually tough business. Magic solutions are not just around the corner. It is the time for the practitioner to examine evolutionary improvements rather than to wait-or hope- for revolutionary ones.

Discussion

I agree with most of the things he says in Chapter 16. However, I believe we have improved a lot in meeting customer needs and this in turn has helped improve productivity. Probably not a lot compared to how much more productive these methods should have become. In any case, he is right about how tough of a business is software development and how we should be examining evolutionary improvements. 

The Mythical Man-Month Ch 13 - 15

Summary

Chapter 13 – The Whole and The Parts – this chapter is about integration of system component and how hard this can be. The chapter explains several methodologies we can follow to make the process easier. It talks about top-down design and how this type of design can avoid bugs. Also, time-shared debugging and system debugging can make the process much easier.

Chapter 14 – Hatching a Catastrophe – this chapter is about the importance of concrete milestones in the development of software to avoid major problems. The chapter discusses how essential is to have a schedule and to keep pert charts updated. Also, managers must reduce role conflict in order to get accurate information from their employees and avoid future disasters.

Chapter 15 – The Other Face – this chapter is about documentation and its importance. Different levels of documentation are required for different users and the programmers who write the documentation must understand that. The chapter also talks about flow-charts and how they are not as useful as they seem to be. One last thing the chapter talks about is self-documentation. Programs should be easy to read and understand without the need to understand every line of code.

Discussion

I enjoyed chapter 14 because it talks about the importance of communication in teams. We can see how bad communication can affect a project outcome all the time. If the manager of a project is open, not giving orders all the time, and easily approachable then the project will be much more successful. I think this is a really key point in project development. Also, I found really interesting how the book downplays the function of flow-charts in projects. I mostly agree with the book but I do believe they can also be useful, it all depends on how you develop them and for what do you use it for.

The Mythical Man-Month Ch 10 - 12

Summary

Chapter 10 - The Documentary Hypothesis – the chapter discusses the importance of having and maintaining formal documents when dealing with a software project. There are several reasons why doing this is important. First, writing decisions down is essential as it solidifies them and makes them clearer. Second, the documents will communicate the decisions to others that migh not know them yet. Finally, a manager’s documents give him a database and checklist.

 

Chapter 11 – Plant to Throw One Away – this chapter is about change and how we should plan for it. We should know that the system and the organization will change. The system will change as we realize not everything is going to work as we expected it. The management structure will change as the system changes, and we must be preared for it. Also, even after the program is delivered to customers, changes will continue to happen (program maintenance).

Chapter 12 – Sharp Tools – this chapter is about the tools used in a project. The essential tools are a computer facility, an operating system, a language, utilities, debugging aids, test-case generators, and a text processing system. The chapter then goes on and explains each of those tools.

Discussion

These three chapters address really important topics. First, keeping formal documents of what is done and what decisions get made is a very key part of any project. Second, system and organizational change is obviously happening and encouraging people to accept this is really important. I thought it was really interesting that the book says that programs will be at their best at the beginning (by their first release). You would logically think that the more errors you fix and the more iterations you release the better the system would get, but I guess is just a misconception. Finally, choosing the right tools is a critical part of a project, and the chapters hits on every single key part.  

The Mythical Man-Month Ch 7 - 9

Summary

Chapter 7 – Why did the Tower of Babel fail? – This chapter discusses the importance of communication in a project. Teams should communicate in as many ways as possible; including informally, by meetings, and through a workbook. The project workbook refers to the conglomeration of all the documents produced by all the teams working in the project, including objectives, specifications, standards, etc.  The workbook should be in a direct-access file that every programmer should be able to access and modify.

Chapter 8 – Calling the Shot – this chapter is about programmer’s productivity. The chapter explains several results from different researches on the difference between how long a task actually takes and how long the programmers predict it will take. For some reason, completing a task always seems to take longer than expected.  Mainly because of other factors that programmers don’t take into account when predicting; like sickness, days off, personal time, paperwork, meetings, etc.

Chapter 9 – Ten Pounds in a Five-Pound Sack – this chapter is about the size of programs and its importance. Size needs to be controlled by defining exactly what a module must do when you specify how big it must be. Also, the entire team must work together for that to happen- by thinking about the overall program and not only the piece you are working on.

Discussion

The chapters were interesting, especially Chapter 8. I think it talks about a common problem that all programmers seem to encounter at some point or another. We always predict things will take a shorter amount of time that what they actually do. I think in order to correct this error we should always expect problems along the way. Also, Chapter 7 talked about a really important concept: communication. The idea of having a workbook is really smart and seems applicable to any project, regardless of how small or big.

The Inmates are Running the Asylum Ch 3-5

Summary

Chapter 3 – Wasting Money – This chapter discusses deadline management. A lot of projects are just rushed out the door, and most times this is not the best idea. Is better to have a good program in 6 months than a bad program in 3.  The chapter talks about several points. First, in order to be able to ship a product and ship it right we first must know what “done” looks like; this means we should know from the beginning what exactly do we want t ship and how do we want it to look. Second, we should understand that shipping late is not the end of the world. Third, feature lists are not problem solving tools; as in fact more features doesn’t translate into a better program. Finally, we must understand the actual costs of bad software, including the money spent on technical support. In summary, we should not define the boundaries of a development project only in terms of deadlines and feature lists.

Chapter 4 – The Dancing Bear – the chapters describes what bad software really means. The first problem is that people don’t really realize that they are utilizing bad software; they think that if it gets the job done then is good enough. However, most of these products don’t make the user happy or even more effective. The chapter then goes on and explains how simple products like email programs, scheduling programs, and calendar software fail. So what is wrong with software? According to the chapter it forgets, is lazy, is parsimonious with information, is inflexible, it blames users, and it won’t take responsibility.

Chapter 5 – Customer Disloyalty – this chapter discusses the importance of customer loyalty and how it is achieve. Design is an incredible important part of the process, as it turns a product that can be built and performs well (engineering capability), and that can be distributed and sold profitably (business capability), into something that people really want (design capability.) Based on this, design will get you customer loyalty… and customer loyalty will bring success to a company.

Discussion

I really like all the examples that the book uses as that way it is much easier to understand what they mean. I think it is interesting how in all these book the “feature” problem keeps reappearing. Apparently, it is obvious to everybody except the programmers that are building the software. Also, the importance of customer loyalty is truly remarkable and obvious in today’s market. There are tons of products out there with practically the same exact set of functions and features. However, customer loyalty could make one product successful while all the others fail.

The Mythical Man-Month Ch 4 - 6

Summary

Chapter 4 – Aristocracy, Democracy, and System Design – This chapter is about the importance of conceptual integrity, which means that a system reflects one set of design ideas, instead of many uncoordinated ideas. We tend to think more features is better, but in reality that does not help achieve conceptual integrity as it actually makes the system harder and more complicated to use. Ease of use, then, dictates unity of design. Another problem with achieving this is the fact that systems are built my many people, and in turn many heads that think differently. Separating architecture from implementation or using the structuring programming implementation of teams talked in the last chapter can resolve this.

Chapter 5 – The Second-System Effect – this chapter is about the tendency of small, elegant, and successful systems to have bad systems as their successors. The chapter gives several examples of this. The best way to avoid the second-system effect is to be aware that it exists and pay extra attention when developing the second system.

Chapter 6 – Passing the Word – this chapter is about teamwork and how to make sure everyone is on the same page when working on a project together. There are several ways of making this happen. First, have very specific and precise written specifications about the system. Second, require the implementation to include a macro. Third, meet face-to-face with the team a lot. Fourth, understand and accept that there should be more than one implementation of the system. Fifth, keep a telephone log of the team calls and questions. Lastly, test your product a lot!

Discussion

I think it is interesting how all the books we are reading overlap at some point. Chapter 6 of this book talks about teamwork and Chapter 4 about the importance of design as a whole. The chapters have the same ideas as the other books, which I agree with. Mainly that system should be easy to use and have an overall design and idea. Also, teamwork is obviously one of the most important parts of developing a system and it must be monitored closely.

Extreme Programming Installed Ch 22-24

Summary

Chapter 22 – Handling Defects – the chapter talks about “bugs” in the code and how to handle them. The first thing is making sure the users have an easy way of submitting problems, whether it is through email or through a problem reporting tool. After getting these errors we should write them on cards and schedule them according to how urgent they are. When we are ready to work on the bug we should write a test that shows the problem, and then fix it. Finally, try to prevent more problems by understanding how and why the existing problems appeared.

Chapter 23 – Conclusion – This chapter wraps up the book (minus the Bonus Tracks). We should now know that the values of XP are simplicity, communication, feedback, and courage. Basically, the chapter indicates how simple XP is and how useful it has been for the authors.

Chapter 24 – We’ll try – this chapter goes over the importance of estimating tasks from the beginning once again. We should be able to estimate how long any project will take without a problem, as long as we write the user stories and estimate each of them by separate; then we can just add them!

Discussion

The first chapter was interesting as it describes how to handle bugs after a system has already been shipped. However, the chapters are getting repetitive and is easy to anticipate what and how the chapter will word something. Even more, the chapter after the conclusion (bonus) was just a repetition of another chapter of the book.  

The Inmates are Running the Asylum Ch 1-2

Summary

Chapter 1 – Riddles for the Information Age – The chapter starts by giving an example that illustrates how communication can be precise and exact while still being tragically wrong. Computers are known for doing this constantly, mainly because of their poor way of communicating and behaving. The fundamental truth about computers is that they may tell us facts, but they don’t inform us. The author then goes on to talk about different examples of what used to be simple to use artifacts like cameras and alarm clocks and how they have transformed in computers. He believes all of our products will soon behave the same as most obnoxious computers, unless we try something different. The reality is that our computerized tools are too hard to use. The fundamental problem is one of culture, training, and attitude of the people who make them. The high tech industry has inadvertently put programmers and engineers in charge, and when the creators of software-based products examine their handiwork, they overlook how bad it is. They key to solving the problem is interaction design before programming.

Chapter 2 – Cognitive Friction – this chapter is about cognitive friction, or the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes. Software interaction is very high in cognitive friction and we need to find a way to lower that. We could achieve this if interactive products were to be designed by interaction designer instead of by software engineers. By this, the chapter means we should stop postponing design until after programming, and start from designing a system that meets the goals the user is trying to achieve. Difficult interaction is very avoidable, as cognitive friction doesn’t come from the technology, but from the people who control technology. The chapter then goes ahead and explains how to software makers, it seems virtually free to add features so programs eventually get clogged up with features that are rarely used. In reality, each user learns the smallest set of features that he needs to get his work done, and he abandons the rest. Then the author differentiates between apologists and survivors. The first group adopts cognitive friction as a lifestyle, while the second goes underground and accept it as a necessary evil. The chapter finishes by explaining that programmers generally surround themselves with other programmers and fail to see the big picture. As an industry, we are largely in denial about the problem of usable interactive products.

Discussion

The first two chapters of this book were very interesting and actually remind me of The Design of Future Day Things. I agree with most of what the author says, mainly about how we truly need to start designing before we start coding. It is definitely true and obvious that computers are hard to use for non-programmers. The main reason for this is, as the author says, letting the programmers do the design or "letting the inmates run the asylum". The people that will use the software need to be heavily involved in the design of the program before anybody writes a line of code.

The Mythical Man-Month Ch 1 - 3

Summary

 

Chapter 1 – The Tar Pit – this chapter identifies the craft of system programming and the joys and woes inherent in it. The chapter first talks about the evolution of programming systems and how it usually goes from being a simple program to being a system and an actual product. It then goes to explain that programming is so much fun mainly because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men. However, there are also drawbacks; like the fact that we must perform perfectly in order for our program to work, and that once programs are done they seem to be obsolete.

Chapter 2 – The Mythical Man-Month – this chapter is about the cause for most project failures: time. The chapter explains different reasons as why it is that way, including the over optimism of programmers, the man-month myth, constraints of system tests, pressure from customer, and using more manpower as a solution to being behind schedule.

Chapter 3 – The Surgical Team – this chapter discusses the problem of small teams of few sharp people vs. big teams where not everybody is super sharp. The problem is that for really large systems you need a big team. Mills propose a system in where few minds are involved in design and construction but many hands are brought to bear. The chapter then goes on explaining this system more in detail specifying the roles of each member, 10 in total. However, how to scale this up? Well, with separate techniques that will be talk about in other chapters.

Discussion

The chapters of the book were interesting; however, I feel like we didn’t get to talk about the “meat” of anything. I would like to read the next chapters and see what else the author has to say. When he discusses the small vs big teams in software design I think he has a good point about the few bright minds and everybody else just helping. In general, I think it is mostly like that; the brains of a project are always a few and the rest are helping with wathever they can to facilitate the process.  

Extreme Programming Installed Ch 19-21

Summary

Chapter 19 – Steering – This chapter is about the importance of steering an XP project. Over the course of a project a large number of stories become easier and easier to do, however, there will also be stories that take much longer than originally estimated. All you have to do to have a successful process is to assess the situation and steer the project. If some stories are taking more time that what you expected then re-estimate other similar stories and rearrange them if necessary. According to this chapter, the process of selecting and steering will deliver a great product.

Chapter 20 – Steering the Interaction – This chapter is about steering each iteration in an XP project. The main point of each iteration is to complete stories. However, it is not the only thing that matters. We also need to reflect on the initial estimates of stories in order to better predict next stories. We can better achieve this by tracking the tasks. There should be a person assigned to track the stories chosen, the tasks to be done, who signed up, and what their estimate was at least every few days. Tracking is critical in the XP process.

Chapter 21 – Steering the Release – this chapter is, as the title indicates, about steering the release. There are two important things to two at the release level: when are you going to release, and what will you have when you do so. The first thing is to know what’s done, and you can achieve this by using acceptance tests. Then, to know how close you are to release, you just need to know which stories remain to be done. Steering the release is the most critical aspect of XP, and can be achieved by estimating difficulty accurately, measuring performance and refining the estimates.

Discussion

These three chapters were very correlated and were all about steering. I believe that is an important point in any project, whether developed under the XP process or not. Tracking what you have done and what remains to be done is crucial in order to deliver your product on time. The chapters were interesting; however, the fact that they talk about having a person dedicating to tracking seems a little unrealistic.

The Design of Future Things - Ch 6

Summary

Natural Mapping

The chapter discusses communication between machines and people. Good communication requires both sides to understand why things are happening or why not. The problem with machines is that the creators often assume that if the machine works perfectly, then they don’t need to provide people with the information behind its actions. However, in order to have real communication with machines we need their feedback. The problem is that today many devices provide minimal feedback, and it is usually more annoying than informative. So how to provide better feedback? With natural interaction: interaction that doesn’t need explanation. The chapter ends by explaining how the lack of common ground between people and machines is a fundamental problem. However, this is not something that cannot be fix by new design. Successful future design will depend on how well the machine can communicate with its user: in a continuous, unobtrusive, and effective way.

Discussion

I really liked this chapter as it tackles a critical and obvious problem: machine communication. I think the chapter nails down why we need natural interaction between machines and humans. It gives really clear and easy to understand examples. However, as always, is more about this utopian futuristic view than about the concrete steps we need to take towards the goal.  

Extreme Programming Installed Ch 16-18

Summary

Chapter 16 – This chapter is a summary of recommendations to achieve the XP goal of delivering well designed, well crafted, flexible structured, properly documented, and tested computer programs. Here are a few of the many recommendations: don’t try to design the whole system before you start implementing it, don’t try to freeze requirements before you start implementing, don’t produce documents or other artifacts that aren’t being used, don’t separate the team into designers and coders, and don’t build for tomorrow.

Chapter 17 – This chapter is about stories time estimation. A few things to remember are the following: estimate each task that you sign up for, estimate the amount of actual time you will spend working, and pay attention to the actual time you spend working. After a few times of doing this, you will be able to accurately estimate the amount of time tasks will take you.

Chapter 18 – This chapter discusses tracking and reporting approaches. There are 4 major things that need to be tracked and reported: resources, scope, quality, and time. Keep track of key resources, number of developers, testers, etc. Also, keep a close eye on the number of stories over time, how many exist, how many are done, and how many more are expected. Use a standard acceptance-testing graph showing number of tests and number succeeding over time. Finally, track the results of each release plan so you are aware of your time constrains. The chapter goes into more detail of each of these tracking mechanisms.

Discussion

As always, the chapters are short, sweet, and easy to understand. Chapters 16 and 17 were mostly about recapping what has already been said before. Chapter 18 was interesting; however, I feel the book is starting to repeat itself too much. I understand they just want to reiterate in order for the info to really stick with us, but I am getting a little tired of it.

The Design of Future Things - Ch 5

Summary

Automation often satisfactorily performs its tasks but adds an increased need for maintenance. For example, with an automatic coffee maker, we trade a little bit of work at an inconvenient time, with the same or more work at a convenient time. Everything in our society is becoming more and more automated. However, if a system is automated it is not necessarily intelligent, but what the book calls adaptive, because it can continually adapt its behavior to the environment. In any case, automation can be annoying, and even dangerous when intrusive. The chapter gives a couple of examples of non-intrusive systems that fit smoothly into people’s life styles. Finally, the chapter discusses autonomous design versus augmentative design. Autonomous devices can be useful when jobs are dull, dangerous, or dirty. However, people have any unique capabilities that cannot be replicated in machines, and for this reason augmentative technology has proven to make more sense in most cases. 

Discussion

It was easy to relate to this specific chapter, as it is a more realistic one. In general, I really like the book, but sometimes the ideas are too futuristic and not very concrete. This chapter, however, talks about the difficulties of automation nowadays and how we should design devices not to overwrite what we do and add stress, but to complement our skills and make our lives easier. I believe that is the real challenge; cooperation needs to exist between machines and humans. I don’t really want a machine to make decisions for me; but I would like one that would somehow help me make those decisions.

 

Extreme Programming Installed Ch 13-15

Summary

Chapter 13 - Unit Tests – This chapter is about the importance of having automated tests for everything. The best way to write tests is to do it at the beginning – test a little, code a little. After you have design a test that encompasses the entirety of the code you are testing you can release the tests and the code. As the code, the tests will become a permanent part of the system and they need to run at 100 percent all the time. This will ensure an easy incorporation of new code into the system by facilitating the catching of errors promptly. The chapter ends by summarizing the testing steps and answering some testing questions.

Chapter 14 – Test First, by Intention – In this chapter they go through an example in order to illustrate two main points. First, we should write new code only when we have a test that doesn’t work (test-first programming). Second, we should not think about how to do a thing, we should think about what we have to do (programming by intention.)

Chapter 15 – Releasing Changes – This chapter explains the process of releasing code to other programmers in your team. There is essentially three phases for the code in an XP project. First, the local phase, where you and your partner just started working. Second, the release candidate phase, where you have finished your task and are ready to release it. Third, the release to the repository phase, were the code is submitted and is guaranteed to work.  There are two common problems with releasing changes: slow mergers and lost changes. In order to avoid these problems, try to release your changes more frequently, and always back up your source code. 

Discussion 

As with a lot of other chapter in this book I think the material makes a lot of sense but is probably very hard to implement. Having tests for everything is an ideal goal, but a hard one to achieve, especially in a large project. I try to relate everything in this book to our specific senior design project and I have problems doing it especially because our team is super small (just a pair.) However, in general the chapters make a lot of sense and are simple to follow and understand.

The Design of Future Things - Ch 4

Summary

This chapter discusses automation and how we have or could become servants of our machines in the future. For example, he talks about cars and how they have become “computers on wheels.” For now, some of the automation is total, while other parts are sort of controllable for the user. However, he argues that cars will soon start communicating with other cars, exchanging all sorts of interesting information, and becoming more and more automated. According to Dr. Norman, technology will never solve all the problems of humankind, but neither will it enslave us. However, automation can lead to people relaying too much on machines that can easily make mistakes. He gives the example of airplane pilots falling asleep because airplanes are too automated. Although generally it is not extremely dangerous for airplane pilots to fall asleep, it is for car drivers. If indeed cars were completely automated, he argues that it would be safer, but the real problem is the partial automation process, were different cars would have distinct capabilities and automation mechanism and it could lead to confusion and accidents. 

 



Discussion

I enjoyed the chapter, especially because although he paints this remote image of the future he is also very honest about our capabilities as of today. For example, he clearly states that it takes a long time for ideas to become concrete tools. Also, he indicates that changes like the ones he is talking about will not just pop out of nowhere. There will be plenty of warning. Moreover, just by taking a look at the conferences worldview you could accurately predict what is the next big idea. I think most of his general ideas of a futuristic community are really distant. However, as we have been experiencing in the past, small increments will happen rapidly and be widely accepted by society.

Extreme Programming Installed Ch 10-12

Summary 

Chapter 10 – Quick Design Session – The chapter essentially discusses design sessions and for who and why are they useful. After breaking down a story into tasks you might find yourself stuck. If so, get a few people together and spend no more than half an hour designing the solution for the task. After listening to your colleague’s ideas, pick the simple one and start coding.

Chapter 11 – Programming – The chapter talks about several key points for XP programmers. First, all programmers must own all the code, so there are no delays in fixing or making the code better. Second, the code must be as simple as possible. Third, keep refactoring, which is the process of improving the code’s structure while preserving its function. Fourth, integrate code as often as possible. Fifth, use a coding standard. Finally, do not work more than 40 hours per week.

Chapter 12 – Pair Programming – In XP, all code is written by working in pairs. Pair programming means two programmers, side by side, working together to write the program. Both partners have responsibilities during the process and its not just one programmer looking at another one code. They both have to be very involved. If done correctly, pair programming will make you go faster in any situation.

 
Discussion

As with the rest of the chapters I have read, I believe the book is very well written and really easy to follow. However, I think most of the points they made in this three chapters are easy to write and agree on but actually hard to accomplish. For example, integrating code too often and early can sometimes be very difficult, time consuming, and in some occasions pointless. Also, I believe working in pair, side by side in a productive manner, is incredibly hard to achieve. First, it is hard for the driver as sometimes you can’t concentrate with somebody looking over your shoulder. Second, it is also hard for the partner as it is very easy to get lost on somebody elses code. Overall, if all these requirements were followed I don’t doubt it would be a much practical and productive way of programming.

The Design of Future Things - Ch 3

The Design of Future Things

Donald A. Norman
Summary

Chapter three discusses Natural Interaction with machines. Mr. Norman starts by comparing how we relate to machines that beep, like an alarm, the dishwasher, the microwave, etc to the way we react and interact with natural sounds, environmental sounds. It is obviously very different; so why do we design our devices to transmit unnatural sounds? Well, it is the easiest ways for designers to add signals to machines, but sadly, it is also the least natural way of doing it. In the future we should use natural signals, like the sound of boiling water in a kettle, which has no fancy electronics and is naturally produced by the water boiling. This should be the model for other systems. The chapter then goes on to explain how important implicit communication is for intelligent design because it informs without interruption and annoyance. However, designs have become intentionally more silent as the sounds usually used are annoying. These noises, however, could be pleasant if well design. In any case, sight and touch provide alternative modalities as well. The chapter later discusses affordances and how important they are in the design of future things. Also, it talks about how machines should not infer the motives of people or try to second-guess their actions, as this could be unsettling and dangerous. The chapter later talks about risk and how studies have found that when an activity is made safer the accident rate does not change. This means that we tend to somehow keep the risk the same, so if an activity seems safer we will act less carefully when doing it.  We could reverse this and say that the more dangerous something appears to be, the more care the person will exert, so why not make activities look more dangerous in order to make it safer? This sounds a little vague but the chapter actually goes ahead and explains several examples of how we could do this. Finally, Mr. Norman gives several examples of natural interaction devices, including the Segway and Cobots.

Discussion

I find it really interesting how a lot of people in our class are complaining about this book and stating that they believe the author is crazy. In my opinion, everything he says makes a lot of sense. I understand that his ideas might be hard to imagine in today’s world; but if we could actually have a natural interaction with machines I think humanity would be much more productive and happy. I don’t think all of a sudden we are going to get overloaded with these types of machines, but I do believe that gradually we will be using more and more devices in a natural and obvious way; and that is pretty much what he is saying. Hopefully, even devices that already exist and we are accustom to will eventually be reinvented to make our life’s easier and safer.

 

 

Extreme Programming Installed Ch 7-9

Extreme Programming Installed

Ron Jeffries, Ann Anderson, and Chet Hendrickson 

Summary

Small Releases – Chapter 7 talks about releasing workable software little by little, instead of just as a whole at the end. It is very common in projects to change directions. Because of this, releasing early and often could make this change process more dynamic and natural. By doing this, you are also providing the customer with an actual tool that they can evaluate and give you feedback on. However, sometimes it is hard to determine how to this. In order to illustrate this the chapter ends by giving several examples on how we could design small releases in specific and concrete projects.

Customer Defines Releases – Chapter 8 discusses how the customer is involved in the process and how he/she defines the meat of the releases. At first, the customer will write stories and make sure that what he/she wants has business value. Then, the customer will hand those stories to the programmers, who will ask questions and estimate how much time and effort each story will take. Finally, the chapter discusses the release planning meeting, which as the name implies, is to plan the smooth execution of the project, to estimate how much time (in points) will each story take, and how many points per interaction will the team be able to achieve.

Iteration planning meeting outcome

Iteration planning – Chapter 9 is all about planning short iterations with clear objectives. In order for the customer to prepare for the interaction planning meeting he/she should choose the most important stories which points sum to the total of maximum points that the team can manage per week (determined in the release planning meeting). Then, the customer will explain the stories and the programmers will brainstorm engineering tasks, and divide and estimate the work. Finally, the chapter explains a specific planning method for assigning and estimating stories. 

Discussion  

Until now, this book has been incredibly easy and interesting to read. The chapters are concise but at the same time convey a lot of information and are easy to follow. The process described in these three chapters seems very straightforward and useful. However, in my previous experiences with projects I have found small releases hard to implement, as I am usually focus on a specific final outcome. On the other hand, as the book illustrated, most projects can actually be divided into small releases and it truly seems to have a positive effect in the project and team as a whole. I look forward to applying this methodology to my project.

 

 

The Design of Future Things - Ch 2

The Design of Future Things

Donald A. Norman

Summary

Chapter2 is about The Psychology of People & Machines. It starts by explaining how the new kinds of intelligent machines create their own assessments and make their own decisions. However, everyday people generally have problems interacting with these machines, as they don’t understand the logic behind it. Designers seem to believe that many of these devices are so intelligent that no learning is required, the book calls this “automagical”, referring to automatic plus magical. However, we all know that machines are not perfect or completely reliable; for this reason, regular people would like to understand the decisions and reactions of machines in order to accept them better.

It is obvious that machines hardware is very different from human beings. However, the book explains how both machines and humans must function effectively, reliably, and safely in the real world, so the world imposes the same demands and requirement upon all creatures. This is why it later explains how the future of everyday things lies in products that know where they are located and who their owners are and that can communicate with other products and the environment. Today, systems are responsive, but not intelligent. They often fail, mainly because they don’t have a good sensorimotor system, but also because they usually measure different things from people, and have different goals. The chapter finishes by explaining that the fundamental restriction on people’s successful interactions with machines is the lack of common ground between them.

Discussion

I think is really interesting how the book describes the fundamental restriction as being the lack of common ground between machines and us. I have never really though about it that way. I still look at most machines as some sort of dumb objects that make lots of mistakes and make me angry. As the book explains, they are definitely useful but not really intelligent. However, if we could have a common ground with them, as other machines do with themselves, we could reach a different sort of understanding, one that can lead to intelligent interaction with a machine. I would love to know in what actionable way are people trying to do this. Everything the book says makes total sense to me, but are we actually moving towards that direction?

Extreme Programming Installed Ch 4-6

User Stories

Extreme Programming Installed

Ron Jeffries, Ann Anderson, and Chet Hendrickson

Summary

Chapter 4 discusses User Stories. In XP the system is specified entirely through stories. In order to do this, we need to find out what the customer wants, and this is done through informal analysis, or in order words: we just ask the costumer and write it in blank cards (stories.) The book explains this process, and emphasizes how important it is to get comfortable with the cards, we should not be afraid of tearing them apart and writing better stories. At the end, the chapter gives a bunch of sample stories.

Chapter 5 is about Acceptance Tests. The book makes clear that we should always test before we ship, and ideally, we should test right after we program something. There is no more important feedback than early information on how well the program works. Test everything you want working in your program, and do it in an automated way. The chapter finishes by giving a few examples on different scenarios and how you could test them.

Chapter 6 is about Story Estimation. Not all stories are the same size so it is hard to estimate the pace of the project just by looking at how many we have. However, there are several things you can do. For example, you can estimate by comparing stories; often one story is just an elaboration of another one. We can achieve this by ranking stories with a point system, and then just assigning similar points to similar stories. At the beginning, however, there is no comparison to be made so the book explains how we could start assigning points based on the “perfect engineering weeks”. Those weeks where you program perfectly all day every day are a perfect engineering week. For example, if you feel you can do a story in one perfect week, then you would give it one point, and so on. An issue with this approach is when you haven’t done anything like the story you are trying to rank. The book explains how in this case you should do some experimenting in order to find out how much time that type of work could take you. Finally, the chapter ends by giving examples of these types of experimentations, called spike solutions.

Discussion

These three chapters were really informative and actually clarified several doubts I had from reading the previous chapters. The process of user stories makes a lot of sense and seems it could be extremely effective. I have never used this process and look forward to do so in the future. The book clearly explains pretty much every detail about it so I don’t think there are any faults in this work, at least from the perspective of someone that has never used XP programming.

The Design of Future Things - Ch 1

The Design of Future Things

Donald A. Norman

Summary

The book discusses smart technology and the interaction between human beings and machines. The first chapter starts by explaining how there is no real communication between machines and us, essentially because they can’t really understand our needs to the fullest. The problem is that technology is becoming more and more powerful, and non-meaningful collaboration between humans and machines could lead to serious problems. In today’s world, intelligent technology is really limited and incomparable to human decisions. However, it is easy to blame a person for a machine’s bad decision: “he should have done this” “she should have known that”, etc. However, we must start designing for the way people actually behave, and not the way we would like them to behave. Intelligent machines should be easy to use and understand, and they should be tailored to the way humans interact and move about society. When using a machine the interaction should be natural and obvious. We need a partnership with intelligent machines, not a one-way relationship in which someone (or something) is always in control. The chapter ended by explaining that we face many problems with technology that cannot be overcome easily. “We need augmentation, not automation”

Discussion

I read “The Design of Everyday Things”, a book by the same author, about a year ago and I literally couldn’t stop thinking about design for a long time. This book has a different focus but is similar in many aspects and as interesting. Everything, from doors to cars that can drive themselves, should be design to be obvious. Humans tend to get very frustrated with machines, basically because they are hard to figure out and their decisions are sometimes unpredictable and hard to understand. A simple example: signs that say “Pull” in a door should not exist, it should be obvious that you have to pull the door in order to open it by just looking at it and the way it is designed. The same goes for any type of technology, we shouldn’t need to take a course or have special talents to use a machine. I think the point that Mr. Norman is trying to make in the first chapter is that we must realize that as technology becomes more intelligent we also need to be more intelligent about its design. Although I have only read the first chapter of this book I am really looking forward to the next chapters.

Extreme Programming Installed Ch 1-3

Extreme Programming Installed

Ron Jeffries, Ann Anderson, and Chet Hendrickson

Summary

The book is about a software development methodology called Extreme Programming, and it particularly focuses on what makes an XP project work. The first chapter explains the concept of XP and discusses the different players in an XP project. The principle of XP can apply to any moderately sized projects that need to deliver quality software rapidly and flexibly. Let’s take a look at who is needed in the process: customers, programmers and managers. Customers express what must be done in terms of stories. Programmers build the system and keep it integrated at all times so there is always a good version to look at. Finally, managers’ cause, coordinate, report, reward, and remove obstacles for the team.  The first chapter goes into more detail about the responsibilities and rights of these three players. Chapter two discusses the circle of life: define, estimate, choose, and build. It boils down to the need for the customers and programmers to understand that they depend on each other and that dependency could be responsible for the success of the project. The third chapter focuses on communication and its importance in the XP methodology. The customer and programmers need to work in concert and as physically close as possible. Written communications take much more time and effort than face-to-face conversations. However, if the customer cannot be physically present all the time it is important to get someone to represent the customer locally and be constantly in contact with the real customer.

Discussion

The information provided by the first chapters of this book was very informative and useful. I believe it discusses many things that you would think are obvious after you read them but you haven’t really thought about it before. Even for projects that might not be suited for XP, the book may be extremely useful as it has general information applicable to any software development project.

About me

1. What is your name?

Carla Villoria

2. What will you be doing after graduation?

Moving to Seattle and working for Microsoft as a Program Manager

3. List your computing interests (HCI, information retrieval, databases, etc.).

Mostly anything that could combine computer science and social justice/environment (information retrieval, software engineering, CHI, etc)

4. List your computing strengths (a language, focus area, etc.).

C++, Python, and Program Management

5. What was your favorite computer science project that you worked on and why?

All projects from the Information Retrieval class (470) as I found them all very current and relevant.

6. What was your least favorite and why? 

All projects from the Introduction to Computer Systems class (313), specially the malloc function one. What I learned through it was not worth the effort.

 

7. What do you see as the top tech. development of the last 5 years and why?

On a large scale smart phones like the iPhone, Android, and Windows Phone 7 as they have changed the way we interact with computers. On a smaller scale, the EnergyHub Dashboard because it aims at making us (and the world) save energy. Also, twitter, as it has revolutionized social media and the way we stay informed.

8. Provide some insight into your management/coding styles. This could include your preferred coding method, how you use line breaks, what time of day you work best, or any other relevant programming-related facts.

I am not really picky about programming styles, and can adjust to anything.