Vague Words

I decided to remove everything I wrote from this page. It wasn't helping. --RonJeffries

Every so often a disagreement flares up here. It usually centers around some tenet of XP and it involves something like

Do the simplest thing that could possibly work

Members of the C3 team award a lovely FAO Schwartz PropellerBeanie to a developer who digs too deeply into the bag of tricks

Some of us object to these statements as being anti-thinking and anti-experimenting. And it is immediately pointed out that the vague words are there. "dig too deeply" doesn't mean you shouldn't dig deeply when necessary.

Etcetera. Yawn. The statement as written, is correct. But statements have baggage. Implications. They carry assumptions around. And I object to the PropellerBeanie not because I view excess complexity as a good thing, but because an environment where people are judging code and awarding PropellerBeanies is likely to be an environment where people are unlikely to dig deeply into their bag of tricks, whether or not it's appropriate. E.g. an environment where the status quo rules and common practice becomes enshrined. An environment, in short, where a good piece of well-understood (and complex) business software could be written on time and on schedule. But maybe not such a good place for tinkering at the edges and exploring just what these computer things can really do for the company.

-- WilliamGrosso

William, in your work with knowledge representation do you often throw in machine learning, or GeneticAlgorithms when all you really need is a tree structure? I suspect not. This is what is meant by digging too deeply. -- DonWells

If that's all that is being said, then it's something that doesn't need to be said. The fact that it was said led me to believe that something stronger was being asserted. And I objected to the stronger thing. -- WilliamGrosso

It is sad, but it does need to be said explicitly.

The objection is to the use of VagueWords. Tautological, relativistic phrases like "too deeply" (what is deeply? what is too deeply? - - unanswerable, personality-based, relative terms).

''This page is objecting to the use of vague words, certainly. Because, when people make proscriptions with vague words, there's tons of room for misunderstanding.''

Fortunately for us the C3 people are giving the PropellerBeanies away. They get to define what too deep is. When we award our own beanies then we get to decide.

Here is something BertrandMeyer wrote:

Advisory rules, positive or negative, are fraught with the risk of uselessness.

It is said that to distinguish between a principle and a platitude you must consider the negation of the property: only if it is a principle does the negation still make sense, whether or not you agree with it. For example the often quoted software methodology advice "Use variable names that are meaningful" is a platitude, not a principle, since no one in his right mind would suggest using meaningless variable names. To turn this rule into a principle, you must define precise standards for naming variables. Of course in so doing you may find that some readers will disagree with those standards, which is why platitudes are so much more comfortable; but it is the role of a methodological advisor to take such risks.

Advisory rules, by avoiding absolute injunctions are particularly prone to becoming platitudes, as especially reflected in qualifications of the form "whenever possible" or, for advisory negatives, "unless you absolutely need to", the most dishonest formula in software methodology.

(From ObjectOrientedSoftwareConstruction, 2nd Ed.) -- DaveHarris

The negation test mentioned seems to be the MeyerTest. As I noted there, one can make a case for any such statement. And actually there was made a case for "use meaningless names" when there were limits on the length of an identifier. But yes, advisory rules/platitudes that make no distinction are useless.

Perhaps it's true that "no one in his right mind would suggest using meaningless variable names". Nevertheless, actually using names that are literally meaningless is very prevalent. "Meaningless" has a definite meaning. Sure, it is subject to some interpretation, but interpretation is not the issue when a programmer chooses "t" over "totalRevenue".

That said, there are gray areas and degrees. Seems to me that C3 has the most effective way to deal with those. Instead of attempting to completely codify a naming standard, they work closely together and provide feedback to specific situations. So, your partner can suggest "How about totalRevenue instead of totalAmount, because it's more specific". I'm not sure how I would write that in a standards manual without resorting to yet another platitude. -- KielHodges

Djikstra said that you should use meaningless variable names. He said you should always use variables with names like s and t so that programmers will not be fooled into thinking they know what the variables do. If you use meaningless variable names then you have to look at the definitions of the variable to find out what they do. Of course, his variable were all defined with invariants. But it is possible to come up with a world in which "use meaningless variable names" makes sense. -- RalphJohnson

..."completely codify", as an ExaggeratedStatement?, ends up being as vaccuous as VagueWords, just on the other end of the scale... I take you to mean extensively instead of completely. My understanding is that the C3 project does in fact use an extensively codified set of naming rules, that were laid down at the beginning of the rewrite, and so were not developed by them working together and providing feedback to specific situations.

At first I felt abashed at reading this. (left for context) --RonJeffries

I don't think you should feel remotely abashed. I think XP passes BertrandMeyer's test better than 90% of methods. Consider these negations:

..none of these strike me as senseless.

..can make sense (if we define precisely when mercy is appropriate)

...hmmm, that does sound dippy. Perhaps OnceAndOnlyOnce is XP's token platitude?

-- DaveCleal

Maybe, but if you look over at ExtremeNormalFormDefined it seems that even the hard core of XP advocates seem to back off from ultimate OnceAndOnlyOnce --FrankCarver

OK, now I am off subject, but... RepeatInSeveralPlaces? is not the negation of OnceAndOnlyOnce. Because there are two pieces. We must not forget the Once part. Perhaps DistributeFunctionalityToAchieveCorrectCompositeBehaviour? would be the negation. Or not. --DonWells

Once Or Twice. Once Upon a Time. Two To Tango. If It's Worth Doing, It's Worth Doing Lots. What I Tell You Three Times Is True.

I like it. I'll take a six-pack of "what I tell you three times is true" and a case of "if it's worth doing, it's worth doing lots". :-)

Wasn't intended as a sweeping criticism of all XP. XP has some good rules. But it also has some poor ones. And the issue also applies to pages which are not part of XP.

DoSimpleThings is a poor one, as the ComplexIsBetter page shows - the terms are defined to make it a tautology. It might be better phrased as DiscountTheFuture?, or some such. AvoidExceptionsWheneverPossible is poor because it is so vague, and because [was something lost from here?]

Maybe they work better in a coach role, where you have continual contact with the team and can evolve an understanding, and update with judgments on the fly. Meyer was talking about rules written once in books, which a bit different. -- DaveHarris

Why would someone ever use gratuitous complexity? If they put it in, they thought they needed it, or would need it, which is the same thing unless they are discounting the future. That's why I think "DiscountTheFuture?" is a better way to express the same rule. -- DaveHarris

I use complexity when I shouldn't. Sometimes due to not being able to think of the simple solution. Sometimes mistakenly thinking the simple solution couldn't possibly work. Sometimes due to not discounting the future, or not discounting the past. Sometimes due to underestimating how complicated the complex solution will turn out to be.

To me, "gratuitous complexity" is by definition bad code. I do not set out to write bad code. A rule that says, "Don't write bad code" doesn't help me.

Another term for "DiscountTheFuture?" might be "NeverAnticipateOutcomes?". Of course, the rationale for either involves defying itself: if you count on the future, you can count on wasting effort. I think the paradox here suggests there is something missing in this rule.

I know AvoidExceptionsWheneverPossible isn't an ExtremeRule?. That's what I tried to get at with my "(or poor pages)" disclaimer. I've now rewritten that part of my comment. Sorry for the confusion. -- DaveHarris

No Ron you are not wrong. I have just seen exceptions used to avoid having to code methods on classes that would just return a zero anyway. That is, instead of making all the appropriate classes polymorphic, with some of the implementations returning a zero some jangmeister wrappered the method calls with an exception catch. An exception catch that would catch any error what so ever. Talk about hard to debug! -- DonWells

So they thought they needed exceptions and were wrong. More specifically, they thought using exceptions would make the code simpler, and were wrong. It also sounds like they may have been unwilling to refactor aggressively. Catching over-general exceptions is just a bug - how about a rule "DontWriteBugs?"? -- DaveHarris

"Rather than with what we actually wrote" - I'd agree if you'd change that to "rather than with what we actually meant". VagueWords invite misunderstanding. It's not necessarily the fault of the people who misunderstand.

"CodeWithoutExceptions" is a general, vague title. The example it leads with is highly specific; it is the ConvertExceptions idiom. If the page had been called, "DontConvertExceptions?", there would be more scope for agreement. If it was further refined to "DontConvertExceptionsUnlessYouAreWritingAframework?", which is what you actually seemed to think at one point, then I don't think I'd argue at all. -- DaveHarris

For example, "CodeWithoutExceptions" doesn't distinguish between throwing exceptions and catching them. It doesn't distinguish calling library routines which throw exceptions. As I said on one of the other pages, CodeWithoutExceptions is impossible in Smalltalk because every method send potentially throws a stack overflow exception. It's so general it's manifestly untrue. You must mean something different, in which case the title is not just general but over-general, that is, vague. -- DaveHarris

See QualityVsPrescriptionRules, WeaselWords, VaguesDependingOnVagues?

EditText of this page (last edited June 30, 2008) or FindPage with title or text search