John Roland Elliott
John_Roland_Elliott "at" hotmail.com
Fri Jun 14 15:17:03 2002
> A silly example I sometimes use here is the next software requirements:
> If the input 2 is given, then the result must be 4. If the input 4 is
> then the result must be 16.
> General solution, just writing the requirements:
> if input == 2
> then result = 4
> else if input == 4
> then result = 16
> else ERROR
> A solution with a little more thinking:
> result = input * input
> Both solutions do exactly as asked but the last one has a much wider
> Lesson learned: remove unnecesary checks by using the proper routine.
(Nothing whatsoever to do with RFB or VNC, but I can't resist ...)
I think this is really wrong-headed thinking.
The initial coding easily accommodates version 2 of the program, the spec
for which reads "If the input is 3, the result is 10.", whereas the second
coding would have to be rewritten rather than enhanced. (You see the
simple-minded result=input*input perhaps should have been result
=6*input-8.) The initial coding also accommodates version 3 of the program,
the spec for which reads "If the input is anything other than 2, 3, or 4,
the output is 42."
Worse still, if, rather than returning an error when unexpected input is
received, the program returns something predictable, you guarantee that
somebody somewhere will grow to depend on it. It will probably be your
biggest meanest nastiest customer who, if you change it, will throw out your
Probably the absolute worst part of the second coding is that it distances
the code from the spec. The spec doesn't say "The output is the square of
the input." so there should be some compelling reason to make the code read
that way. Imagine the Bombay programmer (who was the maintenance programmer
for the product) trying to implement version 3 if version 2 had been coded
result =6*input-8 and Corni had written the comments in Dutch.