Tales from the Inner Genius

This post is based off the politeness criteria mentioned in The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity.

One way to produce quality software is to design it to behave like a good human workmate. Good human workmates are polite and therefore polite software should have the following human characteristics:

• It is interested in me. When people are interested in other person they will remember things about the person. Software should function similarly. If I set an option or open a file in a particular location, the option should remain set and the file location should be retained the next time I open the program. 
• It is deferential to me. The software should let me do what I want. It does not shoehorn me into doing something in only one way. While the software should be able to offer its opinion on an action I take, it should never judge me. 
• It is forthcoming. Common options are readily available and information is always available. Any information related to the user’s end goal should be intelligently presented. Any tools that would be implicitly available to perform the end goal should be available without making a special request to the software. 
• It has common sense. Common options are not intermingled with uncommon options. Harmless options should not be freely mixed with irreversible options that only a trained professional should use. 
• It anticipates my needs. A software program should be able to use its idle time to get ready for my future actions.

Read the rest of this entry »

One of the key items for a software tester is to know when software is defective. The best definition of a defect that I have been able to find comes from Software Testing (2nd Edition):

1. The software doesn’t do something that the product specification says it should do.

2. The software does something that the product specification says it shouldn’t do.
3. The software does something that the product specification doesn’t mention.
4. The software doesn’t do something that the product specification doesn’t mention but should.
5. The software is difficult to understand, hard to use, slow, or—in the software tester’s eyes—will be viewed by the end user as just plain not right.

Points 1 and 2 above are pretty clear cut. Basically, if the software acts differently than explicitly stated, it is a defect. Defects found of this type are relatively easy to report and usually are not contested by the developers or product manager.

Given that 4 of the 5 rules are related to the specification it shouldn’t surprise us that the specification is typically the number one cause of defects. Why? Because specifications are hard to write. It is difficult to capture the entire design of a feature or product without having concrete examples of what is possible. Customers’ needs can change from the time the spec is born and the time it is implemented.

If we are in a position that is more of a Quality Assurance type of role, then we should be concerned with the quality of the spec. We should take an active part in reviewing it. If we are in a position that is solely testing-based, then we must live with poor specs.

Read the rest of this entry »

I have recently finish reading the book Four Days with Dr. Deming: A Strategy for Modern Methods of Management (Engineering Process Improvement Series) and I would like to share my thoughts on it.

This book is designed to replicate the feeling that a CEO would have had attending one of Dr. Deming’s four day seminars. The book is a relatively quick read and is presented to appeal to multiple learning styles.

Some of the items that strike me as most important in applying Dr Deming’s principles are:

A) Quality needs to be top down to be truly effective.

Bottom up is ineffective. Even if the bottom tier is doing it’s assigned duties in a high quality fashion, they may still not be doing the right thing. It is an employees job to make sure that he “cuts down trees” in as efficient manner as possible. It is a leader’s job to make sure that the employee is in the right “forest.” The employee does not have the visibility to know if he is in the correct forest. This is especially true in software development. The cost of finding a defect increases exponentially the further away from it’s point of origin. If quality is not made a priority for the whole team and is relegated to a Quality Assurance group, the system will not function optimally.

B) Variation always exists.

The identification of “special causes” and “common” causes are key. Special causes can be fixed by the people implementing the process via such things as training. Common causes need to be fixed by changing the process. Until Fred Brook’s Silver Bullet is invented or found, there will always be defects in software from the common causes of variation. Therefore, we need to get individual developers trained to a stable state and then focus on improving the process of development.

C) Systems with only common cause variation are said to be stable.

Stable systems can only change if the process changes. Attempting to provide further training to individuals will be ineffective.

Read the rest of this entry »