When you combine an urge for metrics with a lack of obvious ones, funny things happen. Are these metrics? ''No, see MetricsRant.''

''SideBySideComparison'' You don't know what good is, but you know better when you see it, so you compare items side by side. Example: WorstThingFirst.

''ForcedAlignment'' You force two unmeasurable things into alignment. Example: DoWhatYouSaySayWhatYouDo.

''ConvertToCompletionProblem'' Instead of trying to maximize something, you complete something. Example: UnitTest''''''s (complete coverage, complete success)

''SmallSuitcase'' By packing things into a suitcase that holds only a small number of items, you are forced to use some kind of judgement or selection criteria. Examples: Browser windows, top ten lists, StoryCard, IterationPlan.

''SlowLeak'' You give yourself a huge suitcase, but it has a slow leak. Items fade away unless occasionally pulled back into place. Pulling an item back into place takes time and effort. Example: Wiki.

''Relocation'' You carry items from one place to another. This takes time and effort for each item relocated. Examples: Move to a new desk. Move to a new computer.

''ConvertToMinimizationProblem'' Instead of maximizing something unmeasurable like quality or value, you minimize something tangible like defects or redundancy. Examples: SixSigma, OnceAndOnlyOnce.
----
Could this be a metric or is it more of a practice: IfItWorksBreakIt

This comes from the manufacturing industry where they've had arguably good improvements in productivity these last 10-20 years.

It is immediately distasteful. It also flies in the face of a "cornerstone" of communications programming, which is to be concise in what you provide others, and allow slack in what you accept from others (a.k.a. defensive programming).

The basis is that "slack" while shielding people from the defects in the system, also hides those defects so the system is never corrected. If some unusual circumstance happens along that lowers the level of slack afforded the system, the defects are then manifest, and there's a very good chance that the same circumstances that caused the slack to be lower also make this the worst possible time for a system defect to pop up. In manufacturing systems, one of the biggest components is inventories, all over the place, between workstations, at the outgoing loading dock, at the incoming end. As you reduce this "slack" (slowly in the case of a running concern) you begin to expose the problems the system has (the problems the "slack" originally built up to "cover"). Experiments in this very area has led to a whole new understanding of the need for supply chain integration and management tools (the problem that was exposed by reducing the slack).

A software example I can think of is in writing HTML (ok, not code, but it holds and is simple). The worst way to test your HTML is to "try it out" on your favorite browser. This is because most browsers have so much slack in them, that you would never be made aware of many glaring problems in your HTML document. A better way to test would be to write an interpreter that insists on concise HTML syntax and breaks otherwise.  This is a an example of "if it works, break it" as it might apply to HTML document design ("works fine on a normal browser" is not good enough).

Hmmm. AllWarningsOn programming might be a good name except that what's really needed is an understanding of run-time slack conditions.

A way to identify slack, measure it, and then a way to reduce it and measure at what point, if any, the design stops working. I guess that would be my "ultimate metric". --JohnRepici
----
One way to have your slack but not suffer from it is to defensively code the receiving side, introducing slack, but "assert()" the correct restrictive interface. Thus, when debugging, you're working with a "zero slack" interface, but in production, tolerances loosen up, enabling the system to ride over some transients. -- JeffGrigg
----
Oh, wow. If there was ever a time to bring up the FaganDefectFreeProcess this is it. The ultimate metric is correct/not correct.

And now to hear from all the doubters...
----
"Instead of maximizing something unmeasurable like quality or value..."

Both quality and value can be measured easily if the proper measurement units and methods are established. The entire Phil Crosby quality school is based on being able to measure quality in simple terms of dollars and cents. QFD is based on value being measured in relative terms to the entire system.
----
CategoryMetrics