The Mythical Man-Month Ch 18 - 19

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary:

Chapter 18 - Propositions of the mythical man-month:

This chapter provides a brief summary of the book, chapter by chapter and re-iterates the important points from all the chapters. Also, the author provides a set of bullet points that the author thinks are important for the reader to know.

Chapter 19: The mythical man-month after 20 years:

In this chapter, the author talks about the differences between this book and the 1975 edition of the mythical man-month and how things have changes over two decades. The author states that many minor developments have come along however, there have been no major improvements the the way software is built. Programs work, but they don't provide the user a clear conceptual mental model how of the program works and how the user is supposed to navigate through the software. The author criticizes the waterfall development methodology and praises the XP methodology. He says that GUI has made it easy for the user to create mental models, however, he states that windows, icons, menus and pointing interface will soon be obsolete.

Discussion:

Chapter 18 provided an excellent summary of all the important topics that were covered in this book. I think it takes great experience and courage to point out what's wrong with the current software development practices. Also, the author seems very confident while predicting the future trends. This book exposed me to many aspects of programming which were unknown to me.

The Mythical Man-Month Ch 16 - 17

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary:

Chapter 16 - No Silver Bullet

No Silver Bullet was a paper written in 1986 about state of programming. He speaks about two major difficulties with software -

• Essential: difficulties that are inherent in the nature of software.
• Accidental: difficulties that attend to production but are not inherent.

The author says that there won't be any major technological or managerial breakthrough that will significantly improve the productivity.

Chapter 17 - "No Silver Bullet" Refired:

The chapter talks about:

• Complexity - there are huge number of states in the software and no two states are alike. As the size of the program increases, the size if the individual parts increases exponentially.
• Conformity - arbitrary set of rules and changes that a software has to undergo.
• Changeability - constant demand for change during the production of the software
• Invisibility - software is conceptual, it can not be visualized like civil and mechanical structures.

In general, the author says that software development is a difficult and solutions just don't pop in the head. Developing code is a time consuming process which demands hard work.

Discussion:

I enjoyed reading these chapters, however, I somewhat disagree with the author when he says that we haven't improved significantly in the past few years. I think we have developed efficient testing software, programming methodologies and other tools that have significantly improved productivity and quality of the code. Better testing and debugging tools have helped us to deliver almost bug-free codes.

The Mythical Man-Month Ch 13 - 15

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary:

Chapter 13 - The Whole and the Parts:

The whole refers to the system, or the entire project while the parts refer to the individual tasks or features. This chapter talks about the importance of properly integrating the individual tasks into a robust system and how difficult this job can be. He suggests using a top down approach for effective integration and to avoid bugs during the integration process.

Chapter 14 - Hatching a Catastrophe:

In this chapter the author talks about the importance of setting strong milestones. Once these milestones are set, the team must make sure that they are met within the allocated time frame. Author says that once a schedule has been fixed, it's very important to follow it closely. Also, the pert charts must be kept updated at all times. To get the work done from the employees the managers should try to avoid team conflicts.

Chapter 15 - The Other Face:

This chapter talks about the customer view of the program. Depending on various situations, code documentation needs to be prepared for different types of users. Author also talks about flowcharts and states that they are usually produced after the program is complete. The flow charts to be easily comprehend-able should be up to one page long. Furthermore, self-documenting is important i.e. using intuitive variable names and commenting the code.

Discussion:

I liked all the three chapters assigned for this reading. Chapters were very easy to understand and were quite articulate. Now the author seems to be moving on from "getting the code done within the deadline" to the "making it classy" approach. The ideas he suggests in these chapters helps in designing professional quality software products.

The Mythical Man-Month Ch 10 - 12

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary:

Chapter 10 - The Documentary Hypothesis:

This chapter lays focus on the importance of maintaining good documentation during the project cycle. Maintaining proper formal documentation is also a part of effective communication. It's important to write down the decisions that are made during the process since writing them down help people to retain the information and it also makes it clearer for everybody. This ensures that everybody is on the same page and there is no miscommunication. Also, this documentation provides for a checklist to the manager which helps him to track the progress of the project.

Chapter 11 – Plant to Throw One Away:

By "Plan to Throw One Away", the author means to talk about various changes that need to be incorporated into the project during the development cycle. Some changes are incorporated while some are thrown away. The author talks about how we should estimate and plan for changes during the course of the project. Since, not all the features work exactly as we had expected, the system has to undergo changes. Sometimes, the management structure also changes and the team should be ready for it. Changes might continue to appear even after the product is complete and delivered to the customer.

Chapter 12 – Sharp Tools:

This chapter focuses on the various different tools used during the product development cycle. Some of these tools are:

• Computers
• Operating System
• Programming Language
• Utility and debugging tools
• Test case generators
• Text Processing systems
  

The chapter briefly goes over all of these tools, explains their functionality and importance.

Discussion:

I found these three chapter to be very interesting. It looks like this book had a slow start and it's now picking up pace. The chapters are fun to read and not too verbose. The topics covered by these three chapters are very important. I think this book covers some topics that other programming or project management books do not cover. I think the author made really good points by stressing on the importance of documentation and various tools that increase productivity.

The Mythical Man-Month Ch 7 - 9

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary:

Chapter 7 - Why did the Tower of Babel fail?

The author addresses the question - why did the Tower of Babel fail in order to emphasize the importance of communication in any project. Teams should communicate as often as possible using various ways - team meetings, informal meetings, using workbook and logs. Every person on the project should have access to the information presented in the workbook. Workbook is nothing but a collection of all the documents prepared by all the teams about their work.

Chapter 8 - Calling the Shot:

In this chapter, the author talks about the difference between how long the programmer thinks the task will take and the amount of time the task really takes. It's important to understand this difference to make accurate estimates to deliver on time. In almost all cases, tasks take a longer time to complete than it's estimated. The author also talks about various types of data:

• Portman's data -each job takes twice as long as expected.
• Aron's data - regarding programmer productivity on large systems
• Harr's data - productivity falls into two categories: control programs at about 600 words/man-year and language translators at about 2200 words/man-year.
• OS/360 data - confirmed Harr's data.
• Corbato's data - data is comparable in terms of the kind of effort included.

Chapter 9 - Ten pounds in a five pound sack:

In this chapter, the author mentions tat the size control (controlling the size of the programs) is very vital for project's success. It's important to think about the overall code rather than thinking about the snippet that you are currently working on. Space wise expensive programs are not effective. More space the program takes, more memory it will consume.

Discussion:

These chapters mentioned some brilliant ideas that were totally unknown to me. For example, various types of data as mentioned in chapter 8. Also, as a programmer I was aware that your programs should be space wise efficient, however, this point was not bought up by any programming methodology book. Also, the author repeats his emphasis on communication in chapter 7, and I completely agree with the author when he says that effective communication is the key to the project's success.

The Inmates are Running the Asylum Ch 3-5

The Mythical Man-Month Ch 4 - 6

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary:

Chapter 4 - Aristocracy , Democracy and System Design:

In this chapter, the author emphasizes on the idea of conceptual integrity. The author states that a uniform and consistent set of design ideas should be followed instead of having multiple uncoordinated ideas. Author mentions that democracy doesn't really work when it comes to the design phase since different people have various different ideas and all of them can't be incorporated. He also mentions that some stages can be worked on in parallel.

Chapter 5 - The Second System Effect:

In this chapter, the author says that designers tend to add all the new ideas that pop in their minds while working on the first phase into the second phase. This introduces many new changes in the design and many of them might not be consistent with the design that was initially thought of, which can eventually lead to a bad design. It's thus important to incorporate only the smart and creative ideas in the second phase and drop the unnecessary ideas.

Chapter 6 - Passing the Word:

In this chapter, the author stresses on the importance of communication and how everyone needs to be kept informed about the progress of the project. To do this, there are written specifications, formal definitions, direct incorporation, and conferences that require all high-level personnel to meet and discuss problems and solutions. A telephone log is suggested for logging questions and answers, and product testing is recommended for checking the programs against specifications. Face-to-face meetings with the team are very important. Finally, the author again emphasizes in thorough testing of the product.

Discussion:

I think reading this book is a little repetitive after reading the extreme programming book. Most concepts overlap. However, This author has slightly differing views from the authors of the book on extreme programming on certain issues. Overall, the ideas presented make complete sense, but achieving everything is definitely not possible, after all, to err is human.

Extreme Programming Installed Ch 22-24

Reference Information:

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary:

Chapter 22 - Handling Defects

In this chapter, the author talk about how the bugs in the code should be handled. Following approach should be followed:

• Have an easy way for the users to report the bugs - email, bug reporting tools etc.
• Once the users submit bug reports, they should scheduled for bug fix depending on the urgency and severity of the bug.
• Write a test case to recreate the bug, fix the bug and write a test case to verify that the bug has been fixed.
• Examine the root cause of the bug and try to prevent more bugs by addressing the problem.

Chapter 23 - Conclusion

This chapter summarizes the book and briefly goes over all the important aspects of eXtreme Programming, which are -

• Simplicity
• Communication
• Feedback
• Courage

Finally, the chapter praises the XP methodology and talks about how useful and productive it has been in the programming world.

Chapter 24 - We'll try

This chapter talks about meeting deadlines and the importance of accurately estimating the tasks. Authors suggest setting realistic goals and deadlines. The programmers should convey these realistic estimates to the managers.

Discussion:

I've enjoyed reading this book. Extreme programming is quite different from other methodologies that I've studied in the past, like the waterfall or the agile methodology. Chapter 22 was interesting since it emphasizes on handling the bugs when the product is already out in the market. Chapter 23 and 24 basically stressed on previously mentioned ideas. Overall, I think this book provides an articulate, yet detailed description of Extreme Programming Methodology.

The Inmates are Running the Asylum Ch 1-2

The Mythical Man-Month Ch 1 - 3

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks
Publisher: Addison-Wesley

Summary:

Chapter 1 - The Tar Pit

In this chapter, the author talks about system programming by referring to it as tar pit. The authors talks about how a small program grows into a big project later becoming a marketable product. He states that the complexities of system programming considerably slows down the process. The author talks about the sheer joy in programming and how it encourages creative thinking. He also mentions that the process of debugging does get pretty boring.

Chapter 2 - The Mythical Man Month

In this chapter, the author addresses various causes for project failures. He mentions that the most common cause is time i.e. inability to meet deadlines. The chapter presents various reasons for why time is mismanaged. By mythical man month he means to differentiate between time in man-hours and productive work-hours. Estimating time in man hours often gives a wrong estimate. Other factors include too much time spent in testing and pressure from the customer. The author finally provides a rule of thumb for properly allocating time for various stages - 1/3 time for planning, 1/6 for coding, 1/4 for testing components and 1/4 time for system testing.

Chapter 3 - The surgical Team

This chapter talks about how to structure the team to increase the effectiveness of the task. He compares an ideal team to a surgical team. Smaller and smarter teams are most efficient but unfortunately, they are not suitable for large projects. A team of reasonable size of 10 can be perfect for such projects. Such teams should be lead by the head surgeon i.e. the lead developer who is responsible for key aspects of design and development. He is assisted by yet another experienced individual. Manager is responsible for administrative work, editor translates the technical jargon used by the development team into documents used by customers, the clerk maintains the records, secretaries provide assistance to these people. A toolsmith creates helpful tools, the tester writes test cases and the language lawyers uses his/her technical acumen and programming language skills for the tricky work.

Discussion:

So far, the books seems pretty interesting, especially because of the way the author puts the information. However, I personally prefer a direct way of stating the facts. I don't mean to be rude, but I prefer the "cut the crap" approach. This is why I liked the Extreme Programming book better. Also, in the rule of thumb, he assigns least amount of time to the coding phase which doesn't make much sense to me. I think design phase should be short, while coding should be done with care and caution.

Extreme Programming Installed Ch 19-21

Reference Information:

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary:

Chapter 19 - Steering

Before starting the XP project, managers plan the direction in which the project should proceed and the milestones that need to be met. This chapter talks about steering the project in the intended direction in order to meet the milestones. Some stories take more time to implement than it was previously estimated while some stories take less time than estimated. This demands for rearranging and splitting the stories in order to make them fit in the iteration.

Chapter 20 - Steering the interaction

This chapter focuses on steering the iteration in the right direction. The goal of each iteration is to complete the stories within that iteration. We need to constantly track the progress and improve the estimates. Sometimes, resources need to be reallocated to steer the project in the right direction. A person is assigned to track the progress of the project. If a team comes to a standstill, the tracker gives them some time to fix the issue, otherwise, he/she goes to the customer for ideas or possible solutions.

Chapter 21 - Steering the release

In this phase, the team is almost done with implementation and testing. This when the managers need to plan the release. This is when the managers need to decide when and what to release. How well the code is working, what has been accomplished and what needs to be deferred.

Discussion:

These three chapters were very similar, the only difference being that Ch. 19 is very general while chapter 21 and 22 get into the specifics. Authors did a great job in convincing the reader the importance of steering the project. However, assigning one person just for tracking the progress is probably not how it works in the industry. This task is usually performed by the program manager, who is also responsible to hold meetings, meet with customers and understand their needs and convey the customer needs to the technical team. Overall, these were great chapter that provided meaningful insight into the XP process.

Extreme Programming Installed Ch 16-18

Reference Information:

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary:

Chapter 16 - Do or Do Not

This chapter outlines the Do's and Don'ts of the extreme programming methodology. Here are few of the suggestions.

Don't:

• Don't design the entire system before you start implementing.
• Don't produce voluminous design documents at the beginning of the implementation phase.
• Don't build for tomorrow.
• Don't separate the team into developers and designers.

Chapter 17 - Experience Improves Estimates

This chapter explains that with each iteration, valuable experience is gained which helps in projecting precise and accurate time and cost estimates for the future iterations. The important steps in task estimation are:

• Estimate each task that you sign up for.
• Estimate the total amount of time that you'll spend in coding.
• Pay close attention to the actual time spent and the estimated time.
• Evaluate how close was your estimate to the actual time spent.

Chapter 18 - Resources, Scope, Quality, Time

This chapter discusses how to evaluate resources, scope of the project, quality and time associated with the project. These four things should always be tracked and reported. Constant evaluation helps the managers to estimate how well the project is doing. It's a good idea to use standardized acceptance testing to indicate the number of successful tasks. Various tools can be used to track the resources, scope, quality and time of the project.

Discussion:

Even though these chapters had something new to add, they were mostly repetitive. On thise positive side, they were not too verbose. Tracking tools and acceptance testing was a new concept that was presented to the readers and I found it quite informative.

Extreme Programming Installed Ch 13-15

Reference Information:

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary:

Chapter 13 - Unit tests

This chapter talks about the automated unit testing process and recommends to test every tiny feature that can possibly break. When there's collective ownership of the code, unit tests must be run every time a new feature is implemented so that the bugs are caught early, thus maintaining the pace of programming. The tests should return 100% results every time before proceeding to the next step. Tests are written from the beginning of the coding process and are continuously updated throughout the entire process. The final code is released only if all milestones are met and only if all tests return 100% results.

Chapter 14 - Test First, by Intention

This is a brief chapter about testing by intention. This chapter says that instead of thinking about "How" to implement something, emphasis must be laid on "What" needs to be implemented. Once you have a clear idea of what needs to be implemented, it's easier to write test cases for those features.

Chapter 15 - Releasing Changes

Three main phases in code release process:

- Local Phase: This is when pairs of programmers start coding.

- Release Candidate Phase: The feature is complete and ready for testing.

- Repository Phase: The feature is thoroughly tested and is guaranteed to work. Now the code is ready to be committed to the repository.

Problems:

- Slow integration: integrate frequently and continuously.

- Lost changes: have a backup of your code at each phase.

Discussion:

Ideas are very well presented. However, no project is ideal. Problems do arise and things often do not turn out as they were expected. All the ideas presented in this book prepare the development team for such situations.

Extreme Programming Installed Ch 10-12

Reference Information:

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary:

Chapter 10- Quick Design Session

This chapter explains why the design phase is vital in the product development cycle. Once you have the stories and the list of the tasks that need to be implemented, it's important to plan the design of the tasks before moving on to the implementation (programming) phase. Even though the design phase is important, one should not spend too much time designing the task since that puts pressure on the implementation phase. A few minutes should be spent in brainstorming the design ideas. Once you are done sketching the designs, pick the simplest one that can be implemented in least amount of time and move on to the next phase, which is - programming.

Chapter 11 - Programming

Main points:

• Program in pairs
• Test and commit
• Collective ownership
• Keep it simple
• Refractoring
• Continuous Integrate
• Use a coding standard

Programming in general is significantly different from programming followed in the XP methodology. Programming is paired, each pair works on a single task (explained in detail in the next chapter). Once the task is complete, the code is tested and then it's committed to the repository. The ownership rights for the code are collectively owned by the team of developers and quick changes can be made in the code by anyone as and when required. Also, the code has to be simple to understand since other people would be working on features that depend on your implementation. Refractoring helps in improving the overall structure of the code while preserving the functionality. Using a coding standard is vital to maintain the uniformity of the code.

Chapter 12 - Pair Programming

In extreme programming methodology, all the code is written in pairs. A team of two programmers work on a single task at a time. Both programmers share equal responsibility when it comes to writing code. Programming in pairs can expedite the process since one person's errors can be caught by the other.

Discussion:

This book is a collection of great ideas put together. Not that these ideas are unheard of, but what extreme programming essentially does is that it incorporates all the ideas that have been proved to be successful in the past into one development model. Using a coding standard, continuous integration, paired programming and collective ownership are excellent ideas. One of the students in the class mentioned that collective programming can have potential limitations. For example, consider a situation where someone misinterprets your code and modifies it, breaking the code. However, the code can be reverted to the earlier revision, so this should not be an issue.

The Design of Future Things - Ch 3, 4, 5, 6

Reference Information:

Title: Design of Future Things

Author: Donald Norman

Publisher: Basic Books, May 2009.

Summary:

Chapter 3 - Natural Interaction:

This chapter focuses on the importance of natural interaction. Most designs use beeps and flashing lights to provide the user with feedback. Don Norman argues that the designers should instead use natural signals. These include environmental sounds and lights, like sound of boiling water in a kettle, thus making them less annoying. Also these types of feedback are easily recognized.

Author also talks about implicit communication and how it can be used in intelligent designs since it provides a feedback without causing interruption. He talks about how softer sounds can be used in intelligent designs to provide feedback without causing annoyance. Furthermore, he talks about affordances and how they can be effectively used in good designs. Affordances provide cues to the user as to how to use the product.

Lastly, the author talks about predictability and natural safety. He mentions that machines should work as predicted by the user. This helps the user to anticipate the machine's behavior and plan actions. Thus the machine and the user can work in coherence. By the idea of natural safety author implies that designers should make dangerous things look dangerous however make them safe internally. This is because as things get safer, people tend to take more risks.

Chapter 4 - Servants of our Machines:

This chapter talks about the drawbacks of automating. Since modern machines perform most of the tasks themselves, we are becoming dumber. In fact, we are becoming servants of our machines, depending on them for almost all of our tasks. However, we are so used to using machines that this situation can not be reverted. Whenever we see a new technology, it always brings along new benefits, however, what it also brings along with it are some unanticipated problems.

To provide with some examples, author mentions cars that have automated features like cruise control. He states cars are the most advanced area of automation that impact our lives in the most direct way. Eventually cars will get even more automated and start communicating with each other, sharing information. He mentions that complete automation is reasonably safe, however, the present state of partial automation can be disastrous.

Chapter 5 - The Role of Automation:

The author states that "automation is needed to eliminate the dull, dangerous and the dirty." However, automation can have drawbacks. It changes the way tasks were performed before, sometimes creating additional work. Automation also adds to maintenance. Also, automation doesn't necessarily increase the intelligence of the machine.

Next, the author talks about automation and intelligent augmentation. Automation attempts to infer the intentions of the people while intelligent augmentation provides useful tools and lets the people decide when and where they want to use them. Automation is helpful when the jobs are dangerous, dirty, laborious or boring. However, for other cases, author suggests using intelligent augmentation.

Chapter 6 - Communicating with our Machines:

(Chemical Plant Control Room - Controls and Feedback indicators)

This chapter talks about how we communicate with machines and how machines communicate with us by giving the necessary feedback. Communication always occurs between two entities and it helps users to form mental models. These mental models help the users to anticipate the machine's behavior and provide clues to troubleshoot the machine when something goes wrong. However, in modern machines, the indicators that provide the necessary feedback are becoming more silent and hidden, making it harder for the user to guess what's going wrong. Feedback is very necessary to inform the user if the system is working properly. A good design should continuously provide the user with a feedback to indicate the state of the machine, without annoying the user.

The author mentions that the feedback use natural sounds and lights so that they don't get annoying. However, alarm sounds should be annoying since they are meant to catch attention. However, they should not create panic. Also, there should be a natural mapping between the controls and the actual tasks. Some of the characteristics of good design are - predictable, natural feedback signals, good conceptual model and natural mappings.

Discussion:

Chapter 3 - Natural Interaction:

I tried to relate everything that the author mentioned in this chapter with my personal experiences and I realized that everything that the author said made complete sense. I love to use products that aren't too flashy and noisy. Also, I really enjoy using products that are easy to learn and provide me with affordances which expedite the learning process. Speaking of natural safety, it's my personal experience that I used to drive carefully in my old car (from the 80s) and as soon as I got my new car, I started cruising at more than 80mph. So I guess it's indeed important to make dangerous things look dangerous.

Chapter 4 - Servants of our Machines:

I completely agree with the author when he says that the process of partial automation is dangerous. For example, the automatic transmission automated the transmission shifting process, the cruise control in the car automated the need to hold down the throttle. However, the steering wheel is not automated. This is partial automation and I have seen people sleeping while driving, which can be extremely dangerous and sometimes fatal.

Chapter 5 - The Role of Automation:

I do agree that automation can make us handicapped. We become so accustomed to automation that we can't work without it. So, its definitely a good idea to limit automation for performing dangerous, dirty, laborious and dull jobs. For other tasks, intelligent designs can still be implemented without automating the tasks.

Chapter 6 - Communicating with our Machines:

This chapter was a little repetitive. Most of the content was repeated from earlier chapter and the Design of Everyday Things book. Even though the content was repetitive, it was not worthless. The information presented made complete sense and the examples mentioned in the chapter were very convincing.

Extreme Programming Installed Ch 7-9

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary:

Chapter 7 - Small Releases

This chapter sheds some light on why it is very important to have small releases while following the extreme programming methodology. The main advantage of small releases is that they provide the customer and the developers with early feedback. This adds to the flexibility of the project. Thus, if the customer requirements change during the course of the project, small releases allow the programmers to incorporate those changes in the product before it's too late.

Chapter 8 - Customer Defines Releases

This chapter focuses on the importance of having customer in the team. The customer is an important part of the process and the customer defines the what he/she wants in each of the releases. The process starts with the customers writing stories to explain the developers what they want. Once these stories are passed on to the developers, the developers clarify their doubts and ask questions about the requirements. Accordingly, the developers give the customer a time estimate to achieve those tasks. Finally, the exploration phase also includes writing and examination of the user stories. This provides for an estimate of the time required and the costs to implement the feature into the product.

Chapter 9 - Iteration Planning

In the iteration planning phase, the developers make a list of tasks and decide the order in which they need to be complemented and the time required to complete each task. This overview with time and cost estimates is then passed on to the customer and the customer decides if he/she needs any changes in the iteration that could maximize the business value of the product. Once the developers and customers settle down on what tasks they need to achieve during the iteration, tasks are assigned to the respective teams.

Discussion:

The book is an clear indicator that it has been written by computer scientists rather than technical writers or English majors. The information is presented in a very articulate and concise manner and in a very lucid language. Each of the development phases mentioned in this book make complete sense. Extreme Programming methodology has been proven to be very successful which is why it's being used extensively in the industry where the speed and accuracy of delivering the product both are very important to stay ahead in the race.

Book Reading #4: Design of Future Things - Ch2

The Psychology of People and Machines

Reference Information:
Title: Design of Future Things
Author: Donald Norman
Publication: Basic Books 2009.

Summary:
In this chapter, Norman explains the psychology of people towards machines. He says that machines are made up of mechanical and electrical parts, on the other hand, humans are made up of highly complex biological tissues, ligaments and muscles. The brain is capable of intense parallel computation that the machines are not. Animals and people have evolved complex systems of perception and action, emotion and cognition. Machines need analogous systems. Human brain has three stages of processing - Visceral, Behavioral an reflective.
Most exciting of future technologies are those that enter into symbiotic relationship i.e. human+machine, for example, car+driver. This splits the processing levels, the machine takes over the visceral levels while the operator takes over the behavioral level. As the technology progresses, the machine is also taking over the behavioral components. Author claims that these systems aren't really intelligent, they are just responsive. All they do is to respond to the sensor signals, as they were programmed to do. Norman argues that for effective communication and interaction between man and machine, there has to be a common ground. The lack of this common ground is a major cause of our inability to communicate with machines.

Discussion:
I've loved reading Norman's writings. The simple examples he provides to support his theories are just awesome. I find all his arguments about difficulty of communication between humans and machines to be extremely convincing, especially, the common ground argument and his argument about the composure of human body vs. a machine.

Book Reading 3: Extreme Programming Installed (CH 4-6)

Sample: User Story
Reference Information:
Title: Extreme Programming Installed
Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson
Publication: Addison-Wesley Professional; 1 edition (October 26, 2000)

Summary:

          User Stories
User story is the short description of the behavior of the system, from the point of view of the user of the system. First step is - analysis i.e. finding out what the customer wants. The user story is the medium of analysis i.e. the medium of communication between the customer and the programmer.User stories are nothing but couple of sentences written on an index card (as shown in the picture above). Sometimes, the stories get complex and the programmer may need to help the customer to write the stories. It's important that complex stories are broken down into simpler stories. How many stories are required depends upon the complexity of the final software product. Stories shown ideally encompass a week or two pf programmer's time. Once the programmer is done implementing the story, the next step is - "acceptance tests."

          Acceptance tests
Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done. It's not a good idea to leave the testing phase to the very end, by this time, the programmers have forgotten what and how they had implemented the features. This leads to long debugging sessions and slows down the project. The code keeps on changing rapidly and the only way to move rapidly with confidence is to have a strong network of tests, both unit and acceptance, that ensure that the changes to the system don't break things that already work. The tests must be automated. Acceptance tests need to be in the same iteration in which the story is scheduled.

          Story Estimation
Customers need to know how much the stories will cost in order to choose which ones to choose and which ones to defer. During the project flow, the story time is estimated by comparison, i.e. the story being addressed is compared to a similar story that has been worked on before. If both the stories are similar in complexity and difficulty, they will take about the same time to complete. This is how programmers estimate the time it takes to finish a story. Its always a good idea to estimate in groups, this helps in reducing errors in estimation. In the beginning of the project, there are no stories to be compared to, which is why spiking is used. Spike involves writing of some sample code so that the programmer will learn enough to estimate.

Discussion:
All the tools mentioned by the author are extremely useful. I have used agile development methodology in one of my classes before and it's extremely effective. Extreme programming is a part of agile methodology, except, it's more like Agile on steroids. It aims for fast actions, rapid results and evaluation without leaving any room for errors. These tools are designed using personal experiences and I can see how they can increase efficiency, accuracy and cost effectiveness.

Book Reading 2: Extreme Programming Installed (CH 1-3)

Reference Information:
Title: Extreme Programming Installed
Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson
Publication: Addison-Wesley Professional; 1 edition (October 26, 2000)

Summary:
"Extreme Programming (XP) is a software development methodology which is a part of Agile development methodology. It is intended to improve software quality and responsiveness to changing customer requirements." The author talks about how to deal with changing requirements. This methodology keeps the system built at all times. The responsibilities are divided among customers, programmers and managers.
The author focuses on the importance of the customer being close to the programmers so that if the programmers have any questions, they can immediately approach the customer. Finally it's the customer who makes the calls. The XP process lets the team predict more accurately how much work can be done in a given time frame. Program is based on a simple, clear design which helps to produce the software quickly. Extreme programming is about careful and continuous design, rapid feedback from extensive testing and development of high quality code. Ownership of the code is shared, so the work doesn't get halted for whatever reason. This methodology makes programmers job easy and gives the customer what they need the most - business value.
The manager on the other hand, doesn't actually do things, but he causes the things to be done, coordinates their doing and reports the results. He is responsible for arranging the meetings, resolving conflicts and for ensuring productivity. The manager also gets to give the rewards.
The main advantages of this methodology is that there is extremely good communication between the client and the programmers. The programmers are given the flexibility to choose what they want to work on. The program is built and ready for deployment at all times.

Discussion:
The methodology is brilliantly designed. The designers have addressed almost all the issues that can go wrong in the software development process. Being a part of the agile methodology, XP is definitely very successful in the modern day software development industry. I have had a personal experience using the agile methodology in one of my classes and have seen how well it works. I firmly believe with the author's opinion that the customer should be on-site and very approachable so that programmer's questions and concerns can be solved immediately, without wasting any time.

Book Reading #1: Design of Future Things - Ch1

Cautious Cars and Cantankerous Kitchens: How Machines Take Control

Reference Information:
Title: Design of Future Things
Author: Donald Norman
Publication: Basic Books 2009.

Summary:
In this chapter the author talks about how machines are getting smarter, and as they are getting smarter, they are taking more and more control. Whenever a task is partially automated, it is essential that each party, human and machine, know what the other is doing and what is intended. For this, there needs to be proper communication/dialogue between the machine and the human. What we see today is one way communication - monologues. And two monologues do not make a dialogue.
As technology becomes more powerful, its failure in terms of collaboration and communication becomes extremely critical. The author stresses on Socrates's point that a technology that gives no opportunity for discussion, explanation or debate is a poor technology. Failure in proper communication can lead to accidents. If the actions of so-called intelligent device lead to an accident, it will probably be blamed on human error.
It is important for us to understand that even though machines are superior to us in some ways like speed, power and consistency, they lack social skills, creativity and imagination. It is this mismatch that matters because this is what gives rise to frustration, anger, disappointment and sometimes, injury. Machines can work very well in controlled environments where there are no unexpected events or human interference. After all, no matter how smart machines get, they will always have only as much sense as the designers were able to program into them, which isn't really much, given that they can't really know what's going on.

Discussion:
I completely agree with what the author has to say about the smart technology and the machines taking over. I believe that the machines will never completely take over and singularity is not possible. However, our dependence on machines and machine intelligence will keep increasing. For example, with the advent of GPS navigation, people don't remember directions any more, they completely rely on the GPS navigation. So, in a situation in which the navigation systems malfunctions, the result would be extreme frustration and disappointment.
The lesson to be learnt here is that it's good to use machines to save time and for convenience, but that doesn't mean that we forget how to get the work done without the machines. Complete reliance on machine intelligence is definitely not something that we desire.

About Me

What is your name?
Jaideep Balekar

What will you be doing after graduation?
Graduate School

List your computing interests
Information storage and retrieval, HCI

List your computing strengths
OOP: Java and C++

What was your favorite computer science project that you worked on and why?
Braitenberg vehicle simulation - CSCE 452 Robotics

What was your least favorite and why?
All projects in Haskell.

What do you see as the top tech. development of the last 5 years and why?
6th Sense - MIT

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 work best at night.