http://www.perlmonks.org?node_id=671721


in reply to "Practices and Principles" to death

I generally find that talk of “best practices” generally comes from the timid, the clueless, or the management. :-D

As you observe, it very quickly devolves into a quest for affirmation by those who wish to pontificate for one reason or another. If you launch an appeal to “best practices,” presto! ... instant crowd. Nobody really understands what you are saying (nor do you), but at least they are all nodding in agreement because all those “experts” ... they published a book, didn't they? ... said it first.

I think that there definitely are “practices” that consistently show themselves to be fruitful among experienced practitioners, and that there are other practices that clearly don't, but the truly experienced discuss them. Discussions and quarrels of that sort occur here every day. But the practitioners don't “list them and name them and sit around endlessly disussing the list.” The talk among experienced practitioners amounts to what an old-time engineer would call “kinks&rdquo:   practical bits of immediately-useful knowledge, passed along around the cracker barrel.

And since we seem to be baring our “pet peeves” here ...

If I do not again hear the word “patterns,” I will be a happy boy. And yet, I sorely wish that I myself had written such an attractive but vacuous book of truisms and sophistry. If I had done so, I probably would not have any further need to write computer-software. Instead, I would instead regularly walk up to podiums in hotel ballrooms while a roomful of upper-managers applauded. I would earn my bountiful living by saying nothing-at-all using just the right words. (I would not have given any of them anything of value with which to cope with their application-deployment problems; I would only have given them a lexicon by which to name them. But I would be wealthy nonetheless, because I knew they couldn't tell the difference.)

  • Comment on Re: "Practices and Principles" to death

Replies are listed 'Best First'.
Re^2: "Practices and Principles" to death
by dragonchild (Archbishop) on Mar 03, 2008 at 21:36 UTC
    Spoken as someone who doesn't understand metainformation. Bravo. You have added nothing to the conversation.

    It is only when something is named that it can be discussed. Period. It is in how the naming boundaries are made that true understanding can come about. Those patterns you deride allow me to discuss rather high-level concepts with other practitioners of the art with much fewer words. This allows me to communicate more clearly and, more importantly, to think more clearly. Abstraction is one of the few attributes of humanity that separates us from the animals, that allows us to survive when we are, frankly, one of the weakest animals in the kingdom.

    Or, to put it bluntly, discussing programming without the metaprogramming is like programming without subroutines.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      You have added nothing to the conversation.

      That is, to say it charmingly, not quite accurate. sundialsvc4 added enough to incite you to answer. Now, if that isn't adding something to the conversation, what is it?

      update: yes, I won't discuss whether sundialsvc4's post or your reply are substantial; but nothingness often begets enlightenment. I didn't add anything, either...

      --shmem 

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]

        Thanks.

        Perhaps I could state my curious opinion in a slightly different way:   focusing too much on “practices and principles” is, IMHO, focusing on the wrong thing.

        The actual code that you write, to do anything at all, is so secondary as to be an afterthought. Usually, most of the code that I have encountered over the years is indeed “a perfectly reasonable implementation of the designer's apparent intent.” When the code that I thereby encountered was pure crap, it was because it was very obvious that the designer was making the whole thing up as he was going along. There was no “intent.” The project was deemed to be “finished” when the coding stopped, and anything and everything that was done thereafter (i.e. to actually finish the project) was chalked-up to “maintenance.”

        If there is really a “best” practice in this business, I submit that it most-essentially consists of:   do not design at the keyboard. Figure out what you intend to do, in all respects, before you attempt to write any code. If the entire project has been worked-out on paper in advance, then broken down into detailed subtasks, then every programmer can simply “do their piece” and they only have to do it once. Guaranteed. You don't have to give a fancy name to some little slice of the code, because by the time you get to that stage the battle has already been won or lost. You are either attaching little names to broken code, which does no good, or you are “gilding the lily,” which also does no good.

        Twittering about buzzwords is no substitute for thorough and careful design ... started and completed before (yes... before!) any(!) coding work is begun.

        The people who insist that what I just said is “pure garbage” have a name for themselves – it's called “extreme programming,” and it boils down to “you're brilliant as long as you deliver ‘no, no, that's not it either’ once a week.”

        You can attach a label to anything. You can write a book, which Tim O'Reilly will happily publish at least for a while, but excessive studying of individual parts does not illustrate how the entire project must fit, and be fitted, together during the all-important pre-construction process.

[reply]

In Section Meditations