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
