Readings for Day 3: My thoughts:

E.M. Wareham: ISO 9000 and the very small firm:

Quickly/Cheaply/Perfectly- You can choose any 2 for a product that can be delivered by a company or an organization.

General aspects of ISO 9000 is listed down. Few of them being:
1. Monitor the work done.
2. Apply corrective action immediately.
3. For every task, identify the steps taken.

Key points:
1. There is a quick-fix part of the system.
2. Feedback loop – preventive action.
3. Training is part of the quality assurance.

The Article talks about a very small firm called Vinculum Services partnership virtually a one-man group was registered for ISO9001 (Vinculum Services) and ISO9002 (Vinculum Products Ltd.). It compares the small firm to a normal company wherein the sub-contractors take the place of a normal employee and the facility used to inspect products was compared to a local store owned by Vinculum.

It is said that however small the organization, every firm is entitled to get registered to satisfy the requirements of ISO9000. But most small firms don’t implement it because o the lack of managerial skills and simply because they don’t want to.
Five important problems to overcome for ISO9000 certification:
1. Cost
2. Time
3. Loss of production during set-up
4. Operation cost
5. Maintenance cost

The article then lists down the problems faced by Vinculum as mentioned above n the one-man band perspective. A general view from the manager is that the company as such as seen those with registration fly high with improvement in their performance and those who gave up the registration did not improve. Customer satisfaction subsequently increases with ISO9000 mark. It further goes on to say that every small organization must study their business, product and its profitability and then apply for a clause.

Philippe Kruchten: In the world of the agile development context is key:

Agile is a software development process. You can define the process in two ways:
1. By enumeration.
2. By some predicate.

The author makes a few comparisons as claims:
Agile as culture: The article talks about the method: AGILE being a culture which ultimately.
Agile as memplex: Much information about managing projects/agile has been accumulating in our brains like memes. But because there are a different set of practices and no same replication (like genes) possible, there is only an illusion left behind with shared understanding.
Agilese: There is mention of the term Jargon. A terminology used by cyberpunk science fiction writer Bruce Sterling coined. Because of the more widespread use of memes; a number of people using jargon are greater and this means that the term begins to lose its meaning. Thus we end up with a large number of people using terms without any context.

Important takeaway: Every business organization is different. Therefore don’t generalize a message in a context you are not aware of. The term ’context’ is very important because that changes the way when a practice is applied and the subsequent result we obtain.
The author concludes by saying that to question any concept and simply not assume it is a better approach, not that he has doubts in the famous agilistas, it is just a common sense and to keep cooler heads.

Charles Fishman: They write the right stuff:

The article starts off explaining the launch of a rocket and what is the total science behind it – pure software. The software is described to be so pure (bug-free) that it equals a healthy human(disease free). It illustrates the significance of the space shuttle software’s significance because it controls a very expensive equipment along with the lives of the astronauts and dreams of the nation. There is also a description of how coders have evolved during these years and what a grown-up program actually looks like. Also, the programmers who have either spent a lot of time working for IBM or in the shuttle software itself are now adults having kids and spouses- a life beyond this program.

Keller says that there is a strict manual by which coders need to write their programs. It will stifle creativity but this is no place for that. There is people’s life hanging on that piece of code they write and it is no movie wherein the astronaut says, “Houston, we have a problem”. Let them show their creativity on changing the process and not the software.

Sometimes certain business only demands faster delivery to their customers without thinking about what the right stuff is. This is being illustrated by the article with the Larson’s example of cutting wafers as fast as possible.

How to create the right stuff?
The answer is the process they invent to write the software. It can be reduced to four simple propositions:
1. The product is only as good as the plan for the product.
2. The best teamwork is a healthy rivalry.
3. The database is the software base.
4. Don’t just fix the mistakes — fix whatever permitted the mistake in the first place.

Article summary based on the above four points:
1. The shuttle programmers write the code after spending a lot of time looking and verifying the blueprints and hence their code is perfect and works the first time. Unlike this, the modern business organization scenario is different. Clients keep changing the design after the first part of the program is already written and this leads to chaotic programming injecting a lot of errors and bugs.
2. In the case of the teamwork being a healthy rivalry, there are two teams who are given the opposite rules to allow. One being the actual coders who are supposed to write a software that is error-free. The other being the testers who are given the task of running multiple simulations and prove that there is an error in the code.
3. The database consists of two main parts: One being the change in the line of code and the reason as to why it was changed. The other being the errors made while writing or testing.
4. When it comes to mistake, accountability is Team Concept. No one-individual is picked and questioned. Finding minor errors lead us to the basics. While going through that process one tends to find significant errors.
5. Getting to understand a piece of code intimately and get more familiar with it as time progresses is what makes the code error-free. And that is a big advantage for the space shuttle program as they are inching closer to a near-perfect program every time they launch a rocket.

Kent Beck: Embracing change with extreme programming.

With relation to the waterfall model where everything was supposed to go smooth, the users did not tell what they wanted clearly and contradicted themselves. This led to the development of short cycles; because long development cycles were not adaptable to changes. The cost of changing single piece of code increases incrementally and therefore the changes had to be made as early in the life cycle.

The article then lists down major practices in XP.

What XP’s think? Stories:

It is said that the most dangerous anomaly is the period before a system goes into production. That is where stories come into play. When you have a 10-person year long project, a month would be sufficient to Coe up with a story where you analyze the basics of what the program will do. It is understood that the time-period is less but providing longer time without the implementation does not sound good for the project either.


The XP’s release only the first set of requirements as priority based on the customer’s requirements. The budget is calculated by measuring the team’s output in terms of estimated stories delivered per unit time. The customers can ask the programmers to calculate the finish date or pick up a date, budget etc..


Iteration in programming language means loop. It starts of by asking the customers their incremental priority list and then the process starts with a plan ->story to be implemented-> Team implementation-> customer specifying function-> run-> loop it.


First job is to find a partner. Usually the code is written with two people at one machine. If any doubts, then there is a short meeting arranged with the customer or the programmer who is skilled in it. Then the partners pick up selective cases to run as tests such that those tests will allow something to learn and they are confident that it would run smoothly.

Now there are two situations:

  1. If the test code runs they continue.
  2. If it doesn’t run then:
    1. Can see a clear way to make it run.
    2. Can see an ugly way to make it run, but can imagine new design that will be good to implement.
    3. Can see an ugly way to run, but can’t imagine anything that can restore this and therefore to make it run ugly is enough.

Testing can also come from customers. It is not just restricted to the testing team.



Other factors include: 

  1. Under-estimation.
  2. Incooperative customers
  3. Turnover 
  4. Changing requirements

In class Reading discussions:

Charles Fishman: They write the right stuff:

Time: Fatcors to consider:

  1. Communication
  2. Co-ordination

Note: Adding more people increases cost and hence delays the project.


Digital projects can have flexible scope. There is a cost to that but still it is do-able.

There is also the term called excessive scope. Product management paradigm. Fix two and trade-off the others. In digital there are four paradigms. 

MoScoW rule:

Mo Must have – necessary

  • S – should have – later
  • Co – Could have – not this time
  • W – want to have – speculative


Not have a software that is bug free. Above everything where you will negotiate. Discuss and degree is the method.

Cost: Factors to consider:

  1. Money
  2. People
  3. Resources

If you take on too less costs- scope is less If you take too much of costs- no co-ordination and hence poor productivity. One thing that agile provides is treating time as an uncontrollable parameter.


Readings for Day 2: My thoughts:

Bill Moggridge: Expressing Experiences in design:

The article discusses 12 case studies in which IDEO has played an important role in the design of everyday products.
Design aspects involving senses like hearing, smell, taste, seeing were portrayed in an abstract way giving the readers a story to follow. Some of the examples are:
1. BBC radio
2. Digital camera – kodak
3. Chocolate kit

The article gives an understanding of what goes into designing everyday objects and how an effective design plays a significant role in engaging the audience(customers). It also gives examples of how one can do innovative products not only by developing something new, but also adding something very niche.

Winston W.Royce: Managing the Development of Large Software Systems:

This article provides a step-by-step guide for computer code developments. It starts off with a basic description of what the process should mandatorily contain and then sub-branches into other areas and how a typical organization must go forward without time & cost overrun.
The steps are:
1. Program design: Here the structure of the program is constructed as a draft.
2. Documentation: Most important part of any software development phase. The documentation is the key to the next successive steps for their smooth functioning.
3. Keeping a version 2(ver 2.0) is important so that the original source code is retained and the copy provided to the customer is operational and for the time-being ‘bug-free’.
4. Testing.
5. Involve the customer.

Steve Sawyer: Software development teams:

For a software development team: there are three generic archetypes:
1. Sequential
2. Group
3. Network


  • Sequential: Good process leads to good products.
  • Group: Good products based on the collective skills and weaknesses of the group members.
  • Network: Product is central; production process is secondary.
  • Hybrid models: Usually an organization’s software development team adopts a hybrid deriving elements from various archetypes.