Consistency and correctness are both four letter words

by Michael S. Kaplan, published on 2005/03/25 20:53 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/25/402444.aspx

Yes, I said it: consistency and correctness are both four letter words.

As I have said before, one of the greatest strengths of NLS is the strong combination of linguistic knowledge and technical strength. The synthesis that these two very different viewpoints can create is so much more compellingly stronger than anything that either could do on its own.

But it can lead to a lot of interesting debates.

Occasionally, when you have someone from a technical background who has delusions of linguistic aptitude, you end up debating with yourself.

In this context, the definitions of the two words (a-la-dictionary.com) are interesting:

Consistency -- Correspondence among related aspects; compatibility. Reliability or uniformity of successive results or events.

Correctness -- To meet a required standard or condition. conformity to fact or truth.

It is easy to see how each can be important -- being able to count on getting the same results in different versions seems very important. But when the result is wrong, doesn't an API that purports to accurately reflect something have the responsibility of breaking consistency with a prior version, preferring consistency with the truth?

And in each case, the price of keeping to the tenet can be quite expensive. Even if you ignore the fact that you will have to defend your approach to the person who sits in the other camp on the particular issue.

In my case, I have to shave the face of the man who makes some of those decisions, which may be one of the reasons I do not shave every day. And there are times I have lost sleep over those decisions, certain that no matter how many people will be happy with a particular decision that somebody will feel that they have been (to borrow the phrase of Lily Tomlin from The West Wing talking about why she was fired the last time she worked in the White House) screwed with their pants on.

So I decided to try to form some principles, so I can stay clean shaven and not lose sleep when I get a chance to do it:

1. If the old data is simply wrong/incorrect and the new data will fix that, then the change should be made. Correctness rules.
2. If the old result feels less than ideal but is not really "wrong" in the same sense as #1, then no change should be made -- backcompat/consistency rules.
3. If the API or method never really implicitly promised perfection in an area, then it should at least be kept to that standard. Keeping a better, more correct standard is the job of a new API or new flag on the existing API, especially if the change may break someone.
4. If documentation does not make the changeability of behavior clear in these cases based on the above criteria, then that documentation should be fixed.

This is the best I can do to minimize the number of four-letter words that I say under my breath when I have to push issues of either consistency or correctness.

This post brought to you by "€" (U+20ac, a.k.a. EURO SIGN)

# AC on 27 Mar 2005 12:32 PM:

# Michael Kaplan on 27 Mar 2005 12:34 PM:

referenced by

go to newer or older post, or back to index or month or day