Caveat emptor -- and measurements

We focus on the development of systems (programs, applications, or apps, depending on the environment) but we must not forget the buyer, the client, or the person who requests the system. They too have responsibilities in the development of the solution.

One overlooked responsibility is the specification for the durability of the system, or its expected life span. A program designed as a quick fix to an immediate problem can be a wonderful thing, but it is not necessarily designed for a long life span. Platforms and development environments change, and programs can be designed for a narrow or general need.

With ownership comes responsibility. A system owner must understand the durability of their systems. We often hear of a temporary fix living for years. Sometimes this is acceptable, yet many times it entails risks. Quick, temporary solutions are just that: hastily assembled solutions to specific problems. There is no guarantee that they will work for all future data.

Yet owners can think that a quick fix today can be used for a long period of time. This is a mistake. It is equivalent to fixing a flat tire with "fix-flat goo" and replacing the tire. The former does repair the flat tire but it does not provide you with a new tire. If you want a new tire, you have to pay for it.

Similarly, if you want a durable software solution, you have to pay for it. If you are willing to accept a temporary solution, you must acknowledge that the solution is temporary and you will have to replace it in the future. You cannot pay for a temporary solution and receive a permanent one. Yet system owners rarely accept this responsibility.

Part of the problem is that we have no way to measure the durability of a solution. A system owner cannot tell the difference between a temporary fix and a permanent solution, other than the project duration and cost. Unlike a physical good, software is unobservable and unmeasurable. With no ability to rate a solution, all solutions look the same.

All solutions are not the same. We need a way to measure solutions and identify their quality.