Tag Archives: agile

Good quality gone bad – Day 66/139

Today I had a good chat with a bunch of great guys working in the fields of Test-driven and Agile development.

Software development is a risky business.

Developing good quality software is a double-edged sword. Firstly, a software always seems to grow by time. Secondly, only a small software can be maintained free of defects. This being the case, it’s a miracle there is any decent software out there in the first place.

How does one get good quality then?

Here’s a short story about quality. Someone can probably point out the original source but this is the version that I heard:

American company buying Japanese components sometime back in the old days.

Americans: Our absolute quality measurement is six defective units per million.

Time passes and the products are delivered.

Japanese: Here are the million units that you ordered. We wondered why you wanted the six defective ones but we packed them here separately.

The lesson here is that quality is a function of the people who do their job. You can try to demand good quality but it’s difficult to enforce.

Luckily, there is a great measurement for quality.

No matter what you do, products, services, software or something else, this method applies. Just ask the customer of your product one question:

Would you recommend our product to your friends?

This was presented to me as the Harley-Davidson measurement. Their customers apparently answer “yes” 97 times of a hundred.

Reality check – Day 60/139

I started today by reading a book called Getting Real by 37 Signals. This book was especially recommended to me by several individuals and it sure delivers what it promises. The basic message is that making things simple is the superior way in almost every respect.

To put the teachings to action I spent the day sharing ideas with my friend who has assumed the role as the lead programmer in our project. After a while of tinkering with our website his message was:

You’ve achieved more in two hours than we did in the past two weeks.

This was obviously a joke but it unveils a part of the reality. It all comes down to three things:

  1. Remove everything unnecessary or confusing.
  2. Keep everything crucial.
  3. Make the crucial things simply work.

I used to work in IT project management and usually it was the customer that stopped a reality check being made on the software. The customer was so far away from the developer in the food chain that even simple things could become overly complex.

Whatever the project you’re working with, keep it as close to the fundamentals as possible. Keep it really simple.