the degree to which a set of inherent characteristics fulfills requirements — ISO 9000 : 2000

The definition is interesting, because it makes no statements about composition or any other property. The only statement it makes is about the fulfillment of requirements.

Software exists because it fulfills a need. These needs are translated into requirements. Secondly software is expected to have certain qualities by it’s users. These are requirements which are many times unwritten. If software does not fulfill most or all the requirements it will be interpreted as poor quality.

Here are some examples of unwritten requirements:

Bugs should be kept to a minimum.
Software should perform well.
Software should be very usable.

Unwritten requirements are not easy to fulfill, and they are ambiguous and subjective. Clearly defining these requirements and expectations. This process is integral to developing software that fulfills users needs and expectations.

Misunderstanding quality is dangerous, and leads to false beliefs. These beliefs cause developers to ignore parts of the software development picture. The only way to consistently build quality software is to define not only the functional requirements, but also the unwritten requirements and expectations.

Bookmark It

When making changes to a section of code, causes other bugs, sometimes recurring, to pop up. I.E. You fix one bug, and three other bugs pop up after you release.

Have you ever worked on code where troubleshooting bugs was like playing a game whack a mole. I have worked on a few applications that seem to have taken this idea to heart.

If you encounter an application that not very stable, many time your options for dealing with it are limited. You just have to work within the constraints of the system. Previously I have mentioned, defensive development as a technique to cope with difficult system. This is an example of controlling what you can, the new code, and fixes you introduce into the system.

When dealing with difficult systems your best weapon is going to be communication. Make everything as clear as possible. Make your new code readable, understandable, and most importantly comment what you changed, and why you needed to change it. Keep documentation on the system. Document critical, and time consuming tasks. If a process took you a week to update, document it, and it will take the next guy half as long.

The most important technique for dealing with difficult systems is asking questions, and making sure you understand what people are asking. Many times “whack a mole” conditions are caused by mis-communication, and lack of knowledge.

Maintaining difficult systems is a reality for many developers. This is as important, or more important of a development skill as creating new applications. Many time maintenance programming is far more difficult than new development, because you have to work outside of your code “comfort zone”.

Bookmark It

The problem is the kitchen staff sacrificed quality to get the orders out faster. The strategy that values speed over quality may win in the short term, but lose the war. Software development is full of stories of making a hack to hit a deadline. This is part of the culture that values working fast, over working right.

Fighting for qaulity can be very difficult, because no one in their right mind would ever say “I am against producing quality software.” The best way to make the case for quality is to lead by example. Quality software will speak for itself, just like quality food speaks for itself. If the food is really great, you may pay a little more, and wait a little longer, but it is worth it.

Bookmark It