Quality Categories

 A big problem with software development is that people have trouble understanding the quality of the work and the consequences of rushing through it. 

Most people think that except for the interface, the rest of it, which is usually the bulk of it, is invisible. That’s not really the case, while it’s not easy to scroll through the code, configuration, and data in order to inspect them, if they are badly done, they set off plenty of long-term problems. Careful tracking of bugs and stability issues always points back to these types of problems, but because of the time lag, people don’t often make the correct associations.  

We need a set of defined categories to list out software quality. This is pretty good:

0. Busted

1. Demo

2. Barely Usable, but Hideous

3. Tolerable

4. Industrial Strength

5. Excellent

0. Busted

• Not enough of it works to do anything practical

• Maybe it doesn’t even build correctly

• It is crashing for weird unknown reasons

• Code is a mess

1. Demo

• Kinda works

• Looks like something that could be moved forward to being usable

• Database is a mess

2. Barely Usable, But Hideous

• Most functionality works

• Navigation or workflow is awkward

• Either the interface is really ugly (hideous externally)

• Or the code is just a huge sloppy mess (hideous internally)

• Bad data in the database

3. Tolerable

• The functionality works, but isn’t elegant

• The screens don’t induce violent seizures

• The code is mostly formatted

• There is some architectural structure to the code

• It’s mostly consistent, not too much redundancy

• The data is mostly clean

4. Industrial Strength

• The screens are usable

• The code is neat and tidy

• The performance is okay

• The dependencies are mostly up-to-date

• There is an ongoing process to clean the database

5. Excellent

• The interface is a work of art

• There is no redundant code, anywhere

• Everything is consistent

• The code flows nicely, it is easy to extend