Is, let’s say, a Seiko Presage Sharp Edged suitable as a dress watch? One way to answer that question is to find an undisputed dress watch—perhaps a Rolex—and compare the Seiko against it. The Rolex may be thinner. More restrained. Its dial may be simpler, its case less assertive, its overall appearance more traditional. Conclusion: the Seiko is not a dress watch.
But something has gone wrong. We did not assess whether the Seiko was suitable as a dress watch. We assessed whether it resembled the Rolex.
The Rolex became a reference object.
That matters because a Rolex is not the definition of a dress watch. It is one implementation of a dress watch. Its proportions, materials, dial layout and styling are particular design choices through which it realizes certain characteristics. By comparing the Seiko directly with the Rolex, we quietly turn those choices into assessment criteria.
We are no longer asking:
Does the Seiko possess the characteristics of a dress watch?
We are asking:
Does the Seiko implement those characteristics in the same way as the Rolex?
A better approach is to define the typical characteristics of a dress watch.
Perhaps:
- restrained proportions;
- an elegant case;
- a leather strap;
- limited complications;
- an appearance that complements rather than dominates formal clothing;
- and the ability to fit comfortably beneath a shirt cuff.
Now we have something closer to a reference model.
Against those characteristics, the answer becomes more interesting. The Seiko may not be the purest or most traditional dress watch. Its case and dial may be more expressive than the classical ideal. But it satisfies enough of the relevant characteristics that it can reasonably function as one. So yes: perhaps it is at least kind of a dress watch.
The assessment changed because we stopped comparing to a reference object and started measuring against a reference model.
Now turn to software. What are the requirements for the new system?
“We don’t really have proper requirements. We don’t have the time, money or capability to define them. But the new system should look and work like the old system.”
So the old system becomes the reference object. The same old system that must be replaced.
Now, with considerably more money at stake, we make exactly the same mistake again. The old system is one implementation of the required business behavior. But instead of identifying that behavior, we copy the implementation. Its screens become requirements. Its workflows become requirements. Its terminology and data structures become requirements. Even its limitations, workarounds and historical accidents risk becoming requirements.
Apparently, the old system is not good enough to keep—but its implementation is good enough to copy. The irony is difficult to miss.
A transformation project begins because the current system is no longer suitable, then uses that same system as the model for the future. We call it transformation, but make resemblance to the past the acceptance criterion.
Of course, the old system can still be useful. It may contain valuable examples, business terminology, accumulated knowledge and behaviors that must not be lost. But it should help us discover the reference model, not replace it.
The real questions remain:
- What must the new system enable?
- Which outcomes must it support?
- Which behaviors must remain possible?
- Which characteristics must it possess?
- Which constraints still matter?
- Which parts of the old system were merely consequences of one particular implementation?
A reference model describes the required behavior and characteristics.
A reference object shows one possible implementation of them.
When the reference object replaces the reference model, one implementation quietly becomes the requirement. And QA verifies the implementation rather than the required behavior.
Leave a Reply