The Mythical Man Month

Reference:

The Mythical Man Month

Frederick P. Brooks, Jr.

1995 Addison-Wesley

Summary:

Ch. 13 - A fair portion of bugs can be eliminated through the correct implementation of a design.  A top-down design can reduce the temptation to apply a cosmetic fix to a faulty design instead of scrapping it and starting anew.  Additionally, the control structures of a program need to be seen as such, and not as individual branch statements.  Methods for debugging components has evolved over the years.  Debugging the entire system goes faster when debugged components and test scaffolding are used.

Ch. 14 - Enough little delays in the production of a system can lead to big problems.  Concrete milestones provide a way to track real progress and determine how that progress relates to the schedule.  Bosses must know when to let a manager handle an issue and when to become personally involved.  An accurate PERT chart can help the boss determine which action to take.

Ch. 15 - Documentation is a key component of system design.  There needs to be documentation for the casual user of a system, the user who depends on a system, and the user who modifies a system.  A flow chart can act as an effective representation of program structure, but should not exceed one page in length.  An effective method in improving program documentation is to merge the program and the documentation together.  Symbolic names, labels, and statements should convey as much information as possible to the reader.  The formatting of code can improve readability, and comments in the code can be used as a vehicle for better documentation.

Discussion:

Ch. 13 - Debugging is one of the most important parts of programming a system, yet it is one of the most difficult to perfect.  There are so many things that can go wrong in a system, and any number of tests will not be able to prove the absence of bugs.  Indeed, all testing can do is prove the presence of bugs, so we must do the best we can to ensure the system has high reliability.

Ch. 14 - Now that I think about it, little delays do have a tendency to add up quickly.  It is truly better to have  'hustle' and perform better than necessary, so that when a small delay does occur it has little effect on the production schedule.

Ch. 15 - Proper documentation is vital to the programmer.  Code that is poorly documented will often make sense to the coder while it is being written, yet seem like a foreign language if the same coder opens it up two weeks later to do some editing.  The disconnect is even greater when another programmer has to perform maintenance on poorly documented code.  I remember a story when one such programmer found a comment that simply read "RIP LVB."  This programmer had no idea what this meant, so spent much time and effort in tracking down the original author of the code to see if the comment contained important information.  It turned out that the author was a classical music buff, and had happened to write that particular bloc of code on the anniversary of Beethoven's death.  In short, an unrelated and unimportant comment resulted in a significant amount of wasted time.  

The Mythical Man Month

Reference:
The Mythical Man Month
Frederick P. Brooks, Jr.
1995 Addison-Wesley

Summary:
Ch. 10 - The critical documents for a computer product are objectives, specifications, schedule, budget, organizational chart, space allocations, estimate, forecast, and prices.  These last three are linked together, and create a spiral that can be beneficial or disastrous to the product.  No matter the product size, a manager is wise to have the necessary project documents.  

Ch. 11 - When building a pilot system, the product manager must accept that the first version, or the pilot system, will be scrapped in favor of a redesigned version with new ideas implemented.  As such, the system need to be designed to be tolerant to change.  Even after the product is delivered, changes will be made.


Ch. 12 - People like to use personalized tools, but from a programming perspective this is not conducive to good communication.  The programmer needs appropriate simulators, compiler and assembly vehicles, program libraries and accounting, program tools, documentation systems, and performance simulators.  High level languages provide increased productivity and debugging speed. 


Discussion:
Ch. 10 - As a project grows, documentation is critical to keep track of what is where, and even what is what.  There are few things worse than having to figure out how a piece of code works because its author did not sufficiently describe it.

Ch. 11 - One of the most stressed concepts in Software Engineering was having a high threshold for change.  Possible changes need to be kept in mind throughout the development cycle, or else you end up with a monolithic program in which any minor change will cause disaster.

Ch. 12 - Having a good toolkit is a essential for the programmer.  It can make complex tasks simple, and it makes the act of programming more accessible and easy to pick up.

The Mythical Man Month - Ch. 7-9

Reference:

The Mythical Man Month

Frederick P. Brooks, Jr.

1995 Addison-Wesley

Chapter 7

Summary:

This chapter uses the Tower of Babel as an example to show that even if a group has all of the manpower, supplies, and technical expertise it needs to complete a project, it can all break down in the face of poor communication.  The need for a project workbook is stressed, as it assists all members of a project in keeping up with progress and changes made.  Finally, it covers the possible heirarchies that a project may have and the combinations of producers and technical directors.

Discussion:

Since pretty much every class with group projects I've had has stressed the importance of good communication, I must assume that they are onto something.  I can certainly see the value in a project workbook, as I've used code repositories to track changes to code and data.  Quite useful, though I am guilty of not always documenting thing to the degree that they should be.

Chapter 8

Summary:

This chapter examines the vast discrepencies between the estimated and actual proctivity of large programming projects.  As a programming project grows larger, it takes exponentially more time to finish.  Estimates, however, typically do not follow the same curve.  It turns out that many estimates assume that all time will be spent coding/debugging, yet fail to take into account meetings, paperwork, illness, etc.  As a result, most of these estimates are off by a factor of two.  Data shows that a possible way to improve programming productivity up to a factor of five is through using a sufficiently high level programming language.

Discussion:

I certainly understand how using a higher level programming languate can increase productivity.  To me, and I assume most others, it is far easier to program in C than in x86 assembly, and even easier to use C++ over C.  I can also see how a smaller group is able to work faster than a large group.  I suppose a special operations group in the armed forces could be used as an analogy.

Chapter 9

Summary:

Size must be considered when writing a program.  If the size of a program or componant becomes too large, the system will suffer massive performance costs.  Thus, one must not only take into consideration how much total space is available, but how much space is available for each componant of the system.  There are several tricks that can be used to decrease the space of a program, so a programmer should be able to step back and evaluate what changes can be made if they are strapped for space.

Discussion:

When reading this chapter I had to remind myself that it was written in 1995 and that memory was not nearly as cheap as it is today.  We have the luxury of not having to consider how large a program is, but it may not always be so.  As such, we need to be able to optimize performance and efficiency of our programs.

Extreme Programming Installed

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2000 Addison-Wesley

Chapter 22

Summary:

Discussion:



Chapter 23

Summary:

Discussion:



Chapter 24

Summary:

Discussion:



The Mythical Man-Month

Reference:
The Mythical Man-Month
Frederick P. Brooks, Jr.
1995 Addison-Wesley

Chapter 4

Summary:

Discussion:



Chapter 5

Summary:

Discussion:



Chapter 6

Summary:

Discussion:



The Inmates are Running the Asylum

Reference:
The Inmates are Running the Asylum
Alan Cooper
2004  Sams

Chapter 3: Wasting Money

Summary:
Deadlines in the software development business are not like deadlines in other professions.  There is often pressure to ship a product on the estimated date of completion, regardless of if the product is truly finished or not.  Many managers compensate by setting a deadline much earlier than when they expect the product to be completed.  As it turns out, a quality product that ships late will most likely be quite successful.  Programmers are more or less in control of what features are implemented in a product, but features are not necissarily good.  A mistake that gets made with multiple iterations is that if someone keeps releasing poor versions of a product, fewer and fewer people will come back to try the latest revision.  Bad software ultimately leads to higher costs, either through increased maintainence or technical support.  Prototypes are valuable, but should be used as a tool to see how the product will work, rather than as a foundation for the final product.

Discussion:
This sounds like a repeat of the software engineering class I took last semester.  I must admit there have been several occasions over the past few years that I felt an assignment had an unreasonable deadline set, and I wonder if the professors were simply being unrealistic or if they were giving us less time that they anticipated it would take.

Chapter 4: The Dancing Bear

Summary:
 Many times, people will be satisfied with a product simply because they don't know that a better alternitive exists.  People are presented flashy products with many options, but these products may not be able to do any one task particularly well.  Many current products follow current norms because it's the way it has always been done, instead of developing features that are useful to the user. 

Discussion:
While I agree that there are improvements that can be made in product development, but some of Cooper's criticisms seem a bit unfair.  Some of his criticisms seem to hindge on an omnipotent programmer who can forsee all possible ways that a product will be used, but is too lazy to implement them.

Chapter 5: Customer Disloyalty

Summary:
Desirability is an aspect of design that increases a product's likability, but is not necissarily needed.  Desirability generates customer loyalty, ensuring repeat business.  A lack of customer loyalty will hamstring a company over the long term.

Discussion:
Customer loyalty is very important and can help drive other peoply to try a product on the recommendation of their friends.  I thought the comparison of Apple, Microsoft and Novell was interesting, and I will be interested to see how things develop in the future.

The Mythical Man Month

Reference:
The Mythical Man Month
Frederick P. Brooks
1995 Addison Wesley

Summary:
Ch 1 -
When people make the claim "I could write a program that does task X better than what is commercially available," they are probably right.  However, they don't take into account that they are programming something for one particular system, and that to make it viable for multiple platforms it must be generalized and maintained.  Programming fulfills a desire to create things that are useful to many people, and it provides a sense of fulfillment.  However, a byproduct of the way programming works is that it has to be perfect, a task which is not necissarily required in everyday life.  While "good enough" will suffice in most situations, one error can bring an entire program crashing down.  In many cases it seems like programming is a mire where ideas get trapped due to the darious problems associated with it.

Ch 2-
Despite the fact that many programs end up limited by amount of time put into them, programmers remain optimistic.  We always assume that "it will surely work this time" while all evidence points to the contrary.  Programming is not like other tasks: one simply cannot accurately estimate how much time will be needed to complete a project based on its size and the number of people working on it.  In fact, adding more people to a project can often increase the amount of time needed to finish a product, as each new person assigned must be brought up to speed.  While the development of a program may be constrained by a customer's schedule, the completion of it is certainly not.  In the end, most program developments that go awry do so because of a lock of calendar time than any other reason.

Ch 3-

Discussion:

The Design of Future Things

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2000 Addison-Wesley
Summary:
Pending
Discussion:
Pending

Extreme Programming Installed

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2000 Addison-Wesley

Chapter 13

Summary:

While coding, it is important to test code in bits and pieces as it is written instead of doing a big test at the end of the project.  Unit testing involves checking to see if input yields the expected output.

Discussion:

Unit testing certainly saves time in the long run, but it is always tempting to forgo intensive testing while coding.  Still, the testing a little bit at a time is far mor efficient than testing a huge block later.



Chapter 14

Summary:

When writing unit tests, it is best to start with little tests.  In addition, the intent behind code should be clear, as opposed to simply having an algorithm.

Discussion:

 Mostly just providing examples of concepts from the previous chapter.



Chapter 15

Summary:

 When working on a team, code management is very important.  A repository is a common structure used to manage code, but team members need to be careful that they don't mess up the code in the repository.

Discussion:

I've used SubVersion on several occasions, and it is certainly an overall boon to a team.  Everyone must know what they are doing though, or else they might commit erroneous changes to the repository and cause major headaches down the line.



The Design of Future Things

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
Norman coveres the differences between intelligent autonomy and intelligent augmentation.  The former concerns systems that try to guess the intentions of people, and the latter provides tools that can be used at the discression of people.  Autonomy should ideally be reserved for dull or dangerous tasks, while augmentative tools leave more power in the hands of the user.

Discussion:
Norman basically just expands on things he talked about earlier in the book.  Autonomy is indeed useful, but when taken for granted can lead to distrust or tragedy.  Augmentation, on the other hand, is optional, so the user has more freedom in deciding the application of a device.

The Design of Future Things: Chapter 4

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
As technology advances, people become more and more dependent on technology.  As the title states, we are becomming servants of out machines.  Before too long, we will likely have cars that drive themselves, systems that decide how to entertain the user, and kitchens that cook for us.  One of the problems that results stems from when machines fail in an automated task, causing the user to suddenly make a decision on what should be done.  However, when the machines perform properly, it can greatly increase our quality of life.

Discussion:
I found the description of a traffic "swarm" interesting, as I did some research into a similar AI topic not too long ago.  I used intersections as a point of reference, and tried to determine how cars could cross paths without ever having to stop.  My eventual conclusion was very similar to what Norman describes, though my description was on a lesser scale.  Though we may be more dependent on technology than in days past, that doesn't necissarily make it a bad thing.

Extreme Programming Installed

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2001 Addison-Wesley

Chapter 10

Summary:Once the tasks for a given story have been decided, a short design session should be held.  This session should act to eliminate any doubts on what needs to be accomplished for the stories.

Discussion:
Makes sense.  A short design session will help to clarify what a task entails.

Chapter 11

Summary:
Since a programming team shares all of the code they write, it is important to have a coding standard that the team follows.  This way there will be less time spent trying to figure out what another member was doing, and more time actually spent coding.  In addition, all the programmers share ownership of the code, so one person can make any needed changes to anothers code.

Discussion:
 I have been in situations before where I needed someone elses code to have some functionality that wasn't there, but I didn't feel comfortable in altering their code without asking them first.  The concept of collective ownership eliminates this problem, so I can see myself making use of it in the future.

Chapter 12

Summary:
Two programmers working together on a common project not only generate more code, but better code. In the end, both programmers have a working knowledge of the subject, instead of each one knowing half of the subject.  Pair Programming is accomplished through having a driver and a partner.  The driver types the code, and the partner actively engages in the development.  The two can switch roles at any point.

Discussion:
 This is something that is new to me.  It sounds like it would be awkward at first, but given enough time I believe I could get used to it.

Extreme Programming Installed: Ch. 7-9

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2001 Addison-Wesley

Chapter 7

Summary:

It is ideal to release small portions of a system under development so that the customer sees real value and gets tangible functionality during the development process.  Some applications can't be released incrementally, but workarounds can be found by interfacing a new system with the old one.  Almost every large system can be divided into subsystems, and by releasing these as able to the customer, the customer gets the best value for their money.

Discussion:

Another key part of the extreme programming I've experienced.  This ties into the user story aspect, in that each story was a piece of functionality, and each story was able to be used upon completion.



Chapter 8

Summary:

 As a customer, one should expect multiple releases for a system.  Each release will have multiple iterations, and during each iteration multiple user stories will be completed.  As a customer, then, one should prepare the user stories, help the programmers estimate the difficulty of each story, and answer any questions they have.  If something isn't going the way you anticipated it, then the issue can easily be brought up at the start of the next sprint.

Discussion:

 Based on my experiences, this still sounds like textbook Extreme Programming.  If nothing else, XP encourages communication between the customer and the programmers.



Chapter 9

Summary:

 Several things have to happen during iteration planning.  A meeting takes place, where the customer presents the user stories to the programmers.  The programmers assist into breaking the stories down into tasks, and determine which of these tasks are necissary to implement the story.  The estimation phase follows, where a programmer sign up for the work they believe they can complete, and they estimate the difficulty of the work.

Discussion:

One of the great things about XP is that people typically get to work on what they wish to work on.  The sign up/estimation phase decreases the chance that someone will have to work on something they don't want to, and increases the chance they will work on something they enjoy.



The Design of Future Things: Ch. 3

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
Though most electronic devices have feedback in the form of flashing lights or buzzers, the information they provide is not always helpful.  At the same time, many devices that employ useful noises become more and more silent.  Norman believes that affordances, or the range of activities that can be performed upon an object, should be integral in designing new things.  In addition, devices should not try to predict the actions of people, but should themselves act in a predictable fashion.  Norman also notes that an effective method of improving safety is to create a sense of danger without actually increasing the danger.  This trick leads people to behave more cautiously than they normally would. 

Discussion:
I am particularly fond of Norman's description of cobots, or robots that collaborate with users.  For example, if a user pushes on the arm of a factory robot, the arm will augment and follow the force from the push.  This leaves people in control of the action, and provides a predictable pattern that the machine follows.  Granted, I'm enthralled with the possibility of the robotic exo-skeleton, but I recognize the more practical uses of cobot technology.

Extreme Programming Installed: Ch 4-6

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
2001 Addison-Wesley

Chapter 4

Summary:

User stories are used to convey what a system needs to be able to do.  They highlight how the customer wants the system to function.  Ideally, stories are written by the customer.  More stories are required with larger and more complex systems, and if a story gets too big it may be broken down into smaller stories.  If needed, new stories may be added/substituted at the beginning of an iteration.

Discussion:

As an XP veteran, I am all too familiar with user stories.  My experiences had my team (the programmers) coming up with the user stories based on the user's specifications, so I can attest that it is better for the customer to provide the actual stories.  Seeing the many stories associated with a large system can be daunting, but it is a good way to break down a large project.



Chapter 5

Summary:

Acceptence tests are used in conjunction with user stories to define when a story has been suitably completed, or accepted.  These tests define certain criterea that the system must be able to do before any specific story is accepted as complete.  Ideally, these tests should be automated and completed in the same iteration that the story is scheduled for.

Discussion:

The acceptence tests are a great way to gague how far a product is from completion.  Though there are times when it seems like the customer is expecting too much from any given feature, in the end these tests make the whole process run smoother. 



Chapter 6

Summary:

To streamline the development process, it is wise to estimate how difficult any given story is.  Therefore, at the beginning of each iteration, the team estimates the difficulty of the stories in that sprint.  As time progresses, estimations are made more accurate through experience and comparison to previous stories.  However, estimates are unreliable when facing a task that nobody is familiar with. 

Discussion:

 In my XP experience, I often found estimations to be useful.  However, there were occasions where they were quite misleading.  Sometimes people would estimate that difficult tasks would be simple and vice versa.  Extimations are a useful tool, but can't necissarily be relied upon.



The Design of Future Things: Chapter 2

Reference:
The Design of Future Things
Donald A. Norman
2007 Basic Books

Summary:
Currently, machines are most likely to automatically perform functions based on the data they get from their surroundings.  In the future, it might be possible for the machine to explain why it is performing a certain action.  In the meantime, there is a wide gulf between how a person interacts with the world and how a machine interacts with the world.  Humans perceive their environments with millions of cells working in unison, while a machine senses the world through powerful, though inflexible, sensors.  As a result, people and machines have little in common.  Machines that acknowledge this gap will often suggest, rather than dictate, actions.  This provides the user with a choice, and avoids the lack of common ground.

Discussion:
The more I read Normon's work, the more I like him.  At one point or another I have thought about topics that he addresses, and I've typically come to the same conclusions that he does.  Given my interest in AI, I would like to see the lack of common ground between machines and humans eliminated, because I think the best way to develop a true AI is through making it experience the world as we do.  It will certainly take time, but I think it can be done.

Extreme Programming Installed Ch. 1-3

Reference:
Extreme Programming Installed
Ron Jeffries, Ann Anderson, Chet Hendrickson
Addison-Wesley Professional, 2000

Summary:
Extreme Programming is a method that involves high team and customer communication.  The customer's requirements are broken up into user stories, and the stories are used as a basis for what the programmers need to accomidate.  Iterations and reviews are a huge part of XP.  The programmer should always do what the customer wants, and the requirements could change at any time.  To maintain good communication, the "Circle of Life" model can be followed.  This model will facilitate learning and keep information current.  If the customer and programmer are able to work together, the project will be steered to success.  In fact, it is better if a customer can be on-site for the duration of the project.  This will prevent guesswork in coding.  If the customer can't be there, then send programmers to visit the customer as often as possible.

Discussion:
Being an old hand at Extreme Programming (specifically Agile), I have to say that this description is in line with my personal experiences.  Communication with the customer is key, and serves to minimize misinterpreted instructions.  In addition, programmers receive knowledge of any changed requirements as quickly as possible.  In short, I would say that Extreme Programming is the most dynamic form of programming that I have experienced.

Extreme Programming diagram

Design of Future Things, Ch. 1

Reference:
Design of Future Things
Donald A. Norman
Basic Books, 2007

Summary:
This chapter emphasized the communication between people and machines, or rather, the lack thereof.  As machines become more and more automated, they take more and more choices out of the hands of their owners.  The intelligent car is an excellent example, able to brake, accelerate, follow turns, and much much more simply based on the environment it's in.  However, this can lead to trouble through misinterpretation of the environment.  The trouble is compounded through lack or human input and through little to no warning of errors.  If the machine makes an incorrect choice, the operator may only have a split second to compensate.  The main problem, Norman argues, is that there is no true dialogue between machine and operator.  The operator issues commands, and the machine issues a response.  This is contrary to interactions between, say, a horse and rider.  Both intelligent beings, they can send each other signals based on their perceptions and interpretations of the environment.  With automated machines, however, there is no true communication.  Norman ends by arguing for machines that augment, not automate, tasks.

Discussion:
Having interacted with several automated machines myself, I completely agree with Norman's analysis.  Until a machine exists that can process an environment in the same way as a human, they will always be guessing the correct action to take in any given situation.  Even if it's the correct action most of the time, it may only take one mistake by a high-powered piece of machinery to radically alter the life of a person.  I also agree that augmentation is preferable to automation.  I'm a big believer in people making their own choices, so as long as they aren't forced into a decision by a machine then I'm okay with it.

Car of the future?

Introduction

Name: Patrick Frith
Post-graduation plans: I intend to go straight into the workforce, though graduate school is a possibility
Computing interests: AI, graphics, robotics
Computing strengths: debugging, C++, Java, functional programming
Favorite CS project: For an AI class I had to write an agent that could navigate a "Wumpus World," or a randomized world that contained elements that would reward or destroy the agent.  I enjoyed it because it really made me think of the best way to navigate a world without any foreknowledge.  In addition, I was able to add some personal touches to the finished product.
Least favorite CS project: In my sophomore year, I had a data structure assignment that involved a large amouont of provided code.  After writing and pouring over code I thought should work, I contacted the TA for the class for help.  We spent hours going over the assignment, and eventually found that the provided code was riddled with runtime errors.  It was far more trouble that it should have been.
Top tech development in the last 5 years: For the general populace, I think the top development has been the proliferation of smartphone technology.

Management/Coding style: I'm not really sure how to describe my coding style, as it seems normal to me.  That being said, I'm adaptable.  I am a night owl, so I do my best work in the late/early (depending on your perspective) hours of the day.

Me