I’ve criticised software because it is, in general, low quality. I define quality software in 3 ways:

1. It strives to be as future proof as reasonably possible.
2. It does not negatively surprise the user.
3. It performs its function correctly.

And now, for more details.

I. Look Towards the Future

Being future proof doesn’t mean something won’t be replaced. To me it means the product has been guaranteed to be replaceable. That the product assists in creating its own replacement. The majority of software products I encounter that are being phased out are very, very hard to work with. They’re not future proof. They are built sometimes with an outlandishly optimistic view that they’ll be around forever. Sometimes they are built to satisfy the needs of the day without thought to the future. Both are equally bad, though it seems the latter is worse. It isn’t, unless you are judging based on intention.

I don’t think it’s too difficult to create products that are future-proof. It is harder. It requires more thinking. However a lot of very smart people already thought of it. Support standards or standard techniques! If an existing standard does 90% use that and fudge the 10%. If there are off the shelf components each must be evaluated. Evaluate on its own future proofing. If a product uses proprietary formats or vendor lock-in it should be avoided at all costs. Even if it is Microsoft. You will be bound to that product. When it comes time to replace that component life is very difficult.

II. A crash is not a surprise.

By negative user surprise I don’t mean the occasional exception that is thrown. That’s normal and I think most users accepting if exceptions are handled gracefully. Negative user surprise is something like this:

1. Grab a mobile device and go to Google.
2. Google for something.
3. Click through on link and be redirected to the mobile site.
4. Re-search on the mobile site to find the original link.
5. (3?) Click through on link and be redirected to the mobile site.

These are unforgivable traits of low quality work. They’re poorly thought out and annoy users. Annoying users is the very worst thing software can do. It happens far too often and for less savvy users they often blame themselves. They walk away saying, “I’m no good with computers.” In reality, it’s some lazy developer who refuses to learn how to do things right.

III. Correct is absolute.

Right is not subjective. It’s defined. If it isn’t defined it must be defined. It is the only measuring stick to compare. The choice of what brand of tool to use is subject. Being correct is an absolute. The problem with most lazy developers is that if the spec doesn’t explicitly say something they omit it. This is why applications die in a horrible mess if phone formats are wrong or something trivial. “Well, the spec didn’t say to allow dashes in phone numbers!” This mentality is stupid and wrong. Even worse than stupid and wrong, it’s lazy. It’s 2011 and we have tools to make all this easy.

Abiding by the spec is only half of the responsibility. This is because most specs are only half way done. The other half of any product is abiding by the spirit of the specification. This is best tested by developers dogfooding. The sad truth is that very, very few developers use the products they build. If they did, they would be ashamed of themselves. Instead they follow the same code paths and never diverge. If they did they would see just how bad their work really is. This is why QA is very important. Developers can spend an hour on their own application and not find bugs a QA person will find in 5 minutes.

The problem is not using the right tools at the right places.

In Summary

Above I mentioned I criticised a software product recently. It was partially because the choice of tools didn’t blend with my own opinion but more that they are not quality. When I asked about it the answer was very political.

This is what we have experience in working with and are faster using it.

The magic “faster” word. This is a very, very dangerous word. Faster makes business owners excited because they equate faster with cheaper. Unfortunately, faster in the context of tool choosing means “worse”. Faster and worse is the most expensive combination. It means inadequate thought, boiler plate code and woeful testing.

The people are very clearly saying, “I don’t invest in myself enough to compare with alternatives.” This means they are either overworked or lazy. Usually it’s lazy.

A developer who does not invest in themselves will not invest in a product. This will invariably lead to poor quality. That poor quality may not be apparent until years later.