1. 5

  2. 3

    Related: https://weblogs.asp.net/alex_papadimoulis/408925

    Alex Papadimoulis brings up an analogy to a carpenter building a shelving unit asking, “Which is best to drive nails? And old shoe or a glass bottle?” Advice at the operational level would be to compare and contrast the characteristics of shoes and glass bottles and try to determine which would be best to drive nails in this circumstance. Advice at the tactical level would be to say, “Go the hardware store and buy a hammer.” Advice at the strategic level would be to ask, “Why are you using nails here?” And finally, advice at the mission level would be, “Why are you even building a shelving unit?”

    1. 3

      I agree with this, and yet I also object.

      Half of the reason I object is outlined in this comment. Here’s the other half.

      Sometimes, doing something “the actual right way” instead of “the best way, given the constraints of the current advice level”, has costs.


      “Which is best to drive nails? An old shoe or a glass bottle?” “Go to the hardware store to buy a hammer.” “Yes, very good, of course a hammer is best, but there are zombies outside, and they will eat me if I leave the house. Now, about my question?”

      The equivalent of the zombies, in the context of software engineering, is the cost of a redesign, of switching, of re-learning, etc.

      Take a real-world example. Suppose someone looked at OborWiki and said to me (apropos of me asking them for some advice on implementing a new feature, perhaps): “Obormot, your wiki system is built on PmWiki, which runs on PHP. But PHP is a terrible language. My advice to you is that you should switch to Rust.”

      Is this useful advice?

      How much effort would it take to “switch to Rust” (or to anything else)? I’d have to re-implement the entirety of the PmWiki software (which has been in active development for a decade and a half), AND all the third-party features, AND then I’d have to… but it doesn’t matter what I’d have to do next, this is already half a lifetime’s work, and for what, exactly? Well, it would be more correct / good / optimal. Ok. Obviously this is absurd advice, and the only sensible response is a dismissive eyeroll.

      Certainly you might say “if only you’d done it the right way from the start…”—but as usual: a lesson is learned, but the damage is irreversible.

      (Note, to pre-empt an obvious but flawed response: this is not a question of sunk costs! It’s a question of what it costs, going forward, to switch to “right” approach on a higher advice level. Often, the cost is so high that the actual choice is “continue to optimize on the current advice level only” vs. “abandon the entire endeavor”.)

      1. 2

        Also, re: Papadimoulis’s specific question on what sort of response to such questions is more useful:

        The operational-level advice may be problematic for exactly the reasons he states. But the answer he gave (or would give) is useless! It’s nothing more than “UR DOIN IT RONG” in more words.

        Ok, so that’s a bad way to store things in a database. Why? In what way? What’s a better way? What is even the category of the problem? Come on, man! Don’t just say “RTFM!!”—give some pointers; some keywords to google, some vague gesturing in the direction of the thing topic, something!

        That sort of “ur doin it rong” response is very hard to distinguish from noise, and even if the advisee takes it to heart, it’s not very actionable; “read a database book”? who has time for that? Yes, that’s the ideal way to go, but if you require someone to read a whole database book before they can proceed on their current task, then they just won’t read anything and will proceed anyway. Whereas if you point them in the direction of some more specific advice, well, then they might actually learn something and improve.

      2. 2

        Good essay. I would add this caveat:

        Sometimes, someone asks you for advice of level N. However, what you know, and what the one who asks you either does not know or does not want to acknowledge, is that no advice of level N will suffice, for their situation; the flaw in their approach is on level N+1.

        (Example: “The wheels aren’t holding the car up; what sort of bolt should I use to ensure that they hold?” —when the problem is that the car has three wheels instead of four; no kind of bolt will fix that problem.)

        Such cases are difficult. You know that no advice you give on level N will work, but no advice you give on level N+1 will be accepted.

        Being open to being told that this is the case, is, I think, a critical part of being rational.

        1. 2

          Yes. That is an excellent succinct summary of one of the major things I wanted to get across with this essay but didn’t state explicitly within it.

          Do you mind if I add it in directly to the wiki page?

          1. 1

            Go for it.

        2. 2

          Here’s the converse of the caveat in my other comment:

          The lower the level, the more objective questions of optimality are.

          At the operations level, optimality is provable/demonstrable. At the mission level, optimality is largely a matter of values. The strategy and tactics levels are in-between. (Externalities are a large part of why tactical and strategic issues cannot be optimized in a totally objective way.)

          This means that sometimes you may get advice on level N+1, which is inapplicable despite the fact that it does indeed offer a “better” way of achieving your level N+2 objectives. What you’re looking for really is level N advice, not “any advice that helps me achieve my top-level goals”.


          “How many wheels should my car have?” “Don’t build a car; they pollute, cause traffic, and are inefficient.” This is almost certainly useless advice; optimality on the mission level, in this case, is strongly entangled with various values, much broader-scope notions of optimal arrangements of society, etc.

          This suggests heuristics for advice-giving and advice-taking:

          For advice-giving: make sure that you understand your advisee’s values / preferences / views on externalities / etc., as these are less changeable than mission-related decisions at any level, but often intrude on the latter.

          For advice-taking: make it clear to your would-be advisor what is the highest level of advice you’re interested in, and why (i.e. make it clear which options on the level(s) above that you have investigated and rejected, i.e. what your constraints are).

          Recent Comments