5 ms·

It may also be a mistake to assume that it's always possible to break down a system into logical parts and simplify that system until it fits your complexity bu

It may also be a mistake to assume that it's always possible to break down a system into logical parts and simplify that system until it fits your complexity budget prior to development without knowing the upper bound of your problem's complexity. Some things still have to be discovered before they can be measured.

morelisp 4y ago
But it doesn’t need to be possible all the time, just often enough to set bounds acceptable to the rest of the organization. And how are you going to know unless you’ve already done it a hundred times, and/or try?
- rekrsiv 4y ago
  The problem with acceptable bounds is when they're applied uniformly to all your code monkeys without adjusting for experience and mental state at any point in time and we can't sample those values in real-time. Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time. Predicting the future of a high entropy system is predicted to always be hard if you're aiming for 99% accuracy. Solving for hard problems AND solving for this particularly hard problem on a daily basis is less energy efficient than if you stop trying to predict the future at every standup and trust that your average best guess while ignoring the future is good enough to keep you going until the end of this task. TL;DR: Spend less energy sampling the efficiency of human creativity and spend more (but still not too much) on removing barriers that limit creativity.
  - morelisp 4y ago
    What pop nonsense. An unpredictable software engineering team is itself a barrier limiting the creativity of the product team (and vice versa). If you don't want to be treated a crank to turn, you also need to bring some self-reflection, compromise, and willingness to communicate to the table.
    - rightbyte 4y ago
      The only way to make good reliable estimates is to pad and roll your thumbs until the nominal time is up. If there are teams that meet targets they are padding for king and country.
      - morelisp 4y ago
        Picking the 99% or top decile or whatever is not padding, it's the actual job of estimating. Anyone who talks about "padding" rather than uncertainty doesn't understand estimating yet.
        rightbyte 4y ago
        Ye I think I might have misunderstood you. I've got Scrum withdrawal syndrome I can't think straight when seeing the word "estimate".
    - rekrsiv 4y ago
      A product team without an engineering process can reliably do nothing (but not vice versa). If you don't want to be treated like an optimization that only makes sense in a large money-printing machine, you need to stop optimizing for money-printing. Communication isn't just about gracefully accepting expected input and feeling good about getting it. It's also about reliably figuring out the logic behind unexpected input to gracefully bridge the gap. So hacking means creatively staring at unpredictable systems until they make sense. You can timebox how long you can afford to stare at it and then incrementally review whether your staring method should be improved or whether it makes more sense to do something else after the timebox but you shouldn't poll the state of the world every day. TL;DR: Stop opening the oven door every 5 minutes, you're losing heat every time. Muffins don't like that.
TameAntelope 4y ago
Your job as an engineer, broadly, is to bring order to the disordered. You only rarely have enough time to fully understand the problem before trying to solve it. The real, fundamental mistake being danced around here is the failure to recognize the inherent tension between product and engineering. Stop fighting, start harmonizing. Understand how you fit into the bigger picture, and “deadlines” vs. “complexity” will start to make more sense. It’s obvious that you aren’t going to make money off of nothing, so you have to build something, and it’s obvious you can’t build something out of thin air, so figure out how to build small, specific things that people will pay for.
- rekrsiv 4y ago
  While I agree that my job is broadly to bring order to the disordered, I would prefer if the disordered accepted that my proposed way of doing things will eventually achieve order without doubting me every morning, as it is after all my job to find the optimal algorithm to order things since I have myself optimized myself to find just that. I don't want to fight, I'm simply unable to process your disorder in real-time.
  - TameAntelope 4y ago
    Ah, you've already fallen into the trap; it's not about the "optimal", it's about the "functional". Very, very few people are paid to find the "optimal" anything. The trust you're looking for can be found once you recognize what it is you're actually being asked for (again, rarely 'optimal', just 'functional').
    - rekrsiv 4y ago
      We just got started and while I still can't find any obvious deficiencies with your thinking, I find you're investing far too much energy in telling me how I should work and not allocating nearly enough energy into describing what your problem is. Are you aware of the traps you're currently in?
      - 4y ago

morelisp 4y ago

But it doesn’t need to be possible all the time, just often enough to set bounds acceptable to the rest of the organization. And how are you going to know unless you’ve already done it a hundred times, and/or try?

rekrsiv 4y ago
The problem with acceptable bounds is when they're applied uniformly to all your code monkeys without adjusting for experience and mental state at any point in time and we can't sample those values in real-time. Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time. Predicting the future of a high entropy system is predicted to always be hard if you're aiming for 99% accuracy. Solving for hard problems AND solving for this particularly hard problem on a daily basis is less energy efficient than if you stop trying to predict the future at every standup and trust that your average best guess while ignoring the future is good enough to keep you going until the end of this task. TL;DR: Spend less energy sampling the efficiency of human creativity and spend more (but still not too much) on removing barriers that limit creativity.
- morelisp 4y ago
  What pop nonsense. An unpredictable software engineering team is itself a barrier limiting the creativity of the product team (and vice versa). If you don't want to be treated a crank to turn, you also need to bring some self-reflection, compromise, and willingness to communicate to the table.
  - rightbyte 4y ago
    The only way to make good reliable estimates is to pad and roll your thumbs until the nominal time is up. If there are teams that meet targets they are padding for king and country.
    - morelisp 4y ago
      Picking the 99% or top decile or whatever is not padding, it's the actual job of estimating. Anyone who talks about "padding" rather than uncertainty doesn't understand estimating yet.
      - rightbyte 4y ago
        Ye I think I might have misunderstood you. I've got Scrum withdrawal syndrome I can't think straight when seeing the word "estimate".
  - rekrsiv 4y ago
    A product team without an engineering process can reliably do nothing (but not vice versa). If you don't want to be treated like an optimization that only makes sense in a large money-printing machine, you need to stop optimizing for money-printing. Communication isn't just about gracefully accepting expected input and feeling good about getting it. It's also about reliably figuring out the logic behind unexpected input to gracefully bridge the gap. So hacking means creatively staring at unpredictable systems until they make sense. You can timebox how long you can afford to stare at it and then incrementally review whether your staring method should be improved or whether it makes more sense to do something else after the timebox but you shouldn't poll the state of the world every day. TL;DR: Stop opening the oven door every 5 minutes, you're losing heat every time. Muffins don't like that.

TameAntelope 4y ago

Your job as an engineer, broadly, is to bring order to the disordered. You only rarely have enough time to fully understand the problem before trying to solve it. The real, fundamental mistake being danced around here is the failure to recognize the inherent tension between product and engineering. Stop fighting, start harmonizing. Understand how you fit into the bigger picture, and “deadlines” vs. “complexity” will start to make more sense. It’s obvious that you aren’t going to make money off of nothing, so you have to build something, and it’s obvious you can’t build something out of thin air, so figure out how to build small, specific things that people will pay for.

rekrsiv 4y ago
While I agree that my job is broadly to bring order to the disordered, I would prefer if the disordered accepted that my proposed way of doing things will eventually achieve order without doubting me every morning, as it is after all my job to find the optimal algorithm to order things since I have myself optimized myself to find just that. I don't want to fight, I'm simply unable to process your disorder in real-time.
- TameAntelope 4y ago
  Ah, you've already fallen into the trap; it's not about the "optimal", it's about the "functional". Very, very few people are paid to find the "optimal" anything. The trust you're looking for can be found once you recognize what it is you're actually being asked for (again, rarely 'optimal', just 'functional').
  - rekrsiv 4y ago
    We just got started and while I still can't find any obvious deficiencies with your thinking, I find you're investing far too much energy in telling me how I should work and not allocating nearly enough energy into describing what your problem is. Are you aware of the traps you're currently in?
    - 4y ago