spares vs. strikes

One objection that apparently is significant, in the context of bowling scorers, is the "spares" vs. "strikes" issue.  Some people are taught that the rule for how you score spares is different from the rule for how you score strikes.

And, in fact, it is different, though the difference is entirely superficial:

With a spare, your score is the score of a two ball frame and the ball after it.  With a strike, your score is the score of a one ball frame and the two balls after it.  In both cases, the complete frame has a score of 10.  In both cases, the relevant score is the total score of three balls.

In other words, instead of:

score=:3 :0

i=.0

score=.''

while.(i<#y) *. 10>#score do.

bonus=. 10 e. +/\ 2{.i}. y

score=.score, +/(2+bonus){.i}.y

i=. i+2-10=i}y

end.

+/score

)

apparently, some people would prefer:

score=:3 :0

i=.0

score=.''

while.(i<#y) *. 10>#score do.

if.    10= i{y       do. score=. score,+/3{.i}.y

elseif.10= +/2{.i}.y do. score=. score,+/3{.i}.y

elseif.1             do. score=. score,+/2{.i}.y

end.

i=. i+2-10=i}y

end.

+/score

)

Now... I have seen a lot of code messed up by micro-management specifications from people that did not understand what they were asking.  So I am wary of a process which allows for these kinds of changes.

Nevertheless, "the customer is always right", so if someone pays extra, I can see writing code like this.

But coding to address someone else's lack of understanding is probably the wrong approach. We have better ways of helping people understand, starting with documentation.

Also, do you change the code again, when the person understands it?  How do you deal with a different person with different misunderstandings?  How do you deal with harsh misunderstandings, which will not allow correctly functioning code?

These are not non-issues, not by any means.  But just because we have a hammer does not mean we need to treat all issues like nails.