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
not because I view excess complexity as a good thing, but
because an environment where people are judging code and awarding PropellerBeanie
s 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.
William, in your work with knowledge representation do you often throw in machine learning, or GeneticAlgorithm
s 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
Fortunately for us the C3 people are giving the PropellerBeanie
s away. They get to define what too deep
is. When we award our own beanies then we get to decide.
Here is something BertrandMeyer
Advisory rules, positive or negative, are fraught with the risk of uselessness.
It is said that to distinguish between a principle and
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.
, 2nd Ed.)
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.
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?
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
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.
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.
" 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