1. 19
  1.  

  2. 3

    I got kind of lost about what part of this was the “easy” stuff. Fixing flaky tests can be quite hard. The whole Maslow’s hierarchy of needs also seemed completely unrelated.

    1. 3

      One interpretation of Maslow’s hierarchy of needs is “if you’re having trouble finding enough food to survive, it’s gonna realllly tough to do things like maintain friendships or produce incredible art or scientific research.”

      One interpretation of Dix’s hierarchy of software needs is “if you’re having trouble getting your tests to pass consistently, it’s gonna be realllly tough to do things like deploy continuously or split your monolith apart into microservices.”

      1. 2

        Yes, but I don’t know what that has to do with being “easy”.

        1. 4

          Finding food is basically always easier than doing scientific research (partly because it’s inherently easier; partly because if finding food is hard, then malnourishment makes doing scientific research harder).

          Similarly, (assuming the point that dix is making) getting your tests to pass is basically always easier than migrating to microservices (partly because it’s inherently easier; partly because making large-scale changes to your software is going to be to be very tough if you can’t be confident that those changes are correct).

          Fixing flaky tests can be certainly be quite hard, but if your reason for not doing it is “it’s too hard”, then tackling even more challenging problems seems like a bad decision.

          1. 2

            It depends on your definition of easy. If one’s version of primitive or generic human lives in the topics, where there are low hanging fruit, by all means pick those. But in full generality, finding food could involve anything from long hours hunting and/planting to long hours at the fastfood joint making the money for the food.

            Scientific research might involve sitting around speculating, it might well be “easy” though it’s payoff time might be long.

            And so, what I see is there’s a confusion between “easy” and “has an immediate payoff”. It’s definitely important to tackle some tasks with an immediate payoff while the stuff with a long payoff percolates along. And it’s good to tackle tasks that are really-easy and have a semi-immediate payoff. But acknowledging this, we’ve got a complex situation, which can’t be that easy, right?

            So what’s easy? Thinking about it, it almost seems like “figuring out what’s easy” isn’t always easy itself. That leads to a paradox. But it might be a “paradox of finite regress” rather than infinite regress. Go for the low hanging fruit, if you can see them. Otherwise, maybe look carefully and you might see them or put out the darn effort, climb the tree and get other if you’re lucky or you’re speculation has borne fruit. It’s altogether not easy, sorry…

            1. 3

              Part of “easy” here has to do with dependence of the “harder” activities on the “easier” ones. It’s entirely possible that cost(eat_low_hanging_fruit) + cost(climb_to_high_limbs_on_a_full_stomach) is less than cost(climb_to_high_limbs_on_an_empty_stomach), despite involving more activity. Similarly, a scientist who has spent most of the day hunting might get more research done in the remainder of the day than the scientist who is plagued by hunger pangs and malnutrition does with their whole day. Similarly, a team that maintains a robust test suite might able able to tackle hard architecture changes more quickly than a team with no test suite at all, despite the total amount of work that has to be done being larger.

              In fact, I’d argue that anyone who writes automated tests believes this implicitly. There’d be no reason to write non-production code if it didn’t make you more effective at writing production code. (That said, it is entirely possible to write tests in a way that actually slows you down.)

              1. 1

                This whole thing is getting a bit ridiculous. Clearly “easy” is the wrong adjective to use for this. If one only do easy things you’ll never do hard things. In general, I pick things with high impact. They may be easy, they may be hard.

                1. 2

                  “Easy” is maybe not the most clear word here, but in the context of the entire post it seems understandable enough.

                  Notice how the title of the post is “Do The Easy Things First”, not “Only Do The Easy Things”. Dix is not advocating to not do things with “high impact”; he’s advocating to set yourself up for success while doing those things, even if that means delaying starting on them to take care of foundational work.

                  1. 1

                    And I am saying if you always do the easy thing first you’ll never get to the hard thing.

                    1. [Comment removed by author]

                      1. 1

                        I’d also argue that if you never have a compelling reason to do the hard things, you shouldn’t do the

                        Your whole argument is to do the easy things first. If that’s the heuristic you want then you won’t do the hard things until you have nothing else to do. This is why I think impact is a more valuable way to look at it.

    2. 1

      Posted on 4/1. Not sure if I should take it seriously.

      1. 4

        I see no reason to think it’s a joke.

        1. 2

          troll

          wasn’t trying to troll. Annoyed by the ridiculous 4/1 tradition and how it seriously does make me question anything I read on 4/1.

        2. 1

          I’m learning a neww codebase right now, it’s quite a mess, but since my boss always gives me enough work for a week in one go, I’m free to explore and solve the easier problems first, so when I get to the harder ones I have a much better understanding of whats going on.