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.