3 ms·

> "Why?" "Because our culture has product managers demanding things with short deadlines and no concern about the code quality." I find answers like this to be

• RealityVoid 5y ago
  At that point, it's not actionable either, it's just blame shifting.
• passivate 5y ago
  Indeed, the five Why's is just one of the starting points for introspection. Each person/team/department/org needs to find ways to generate consensus and actionable items out of that exercise. Reactionary phrases like "because x sucks" aren't very useful.
  • stefan_ 5y ago
    Oh good, we have arrived at the no true scotsman phase. It's not that scrum and agile aren't working, your team just hasn't introspected enough!
    • bumby 5y ago
      Talk to industrial engineers and they’ll tell you these exercises are just a starting point to try and understand the problem. We all like to pretend there are always simple solutions (if I had a nickel for every time somebody told me the root problem was ‘we just need more people’…) but I’m practice, process improvement is often messy and convoluted until you drill deep into the system
    • passivate 5y ago
      If we knew of a perfect system without flaws, we'd already be using it.
• ajkjk 5y ago
  I disagree so strongly with this. There's a pervasive fallacy in the industry that things that aren't quantifiable, or are hard to quantify, can't be real or true. It's just wrong: they can be very true, and often such things are deeply true but whole organizations are ignoring them because they haven't found a convenient way to shoehorn them into their KPIs / OKR framework / whatever. Yes, it is often the case that product managers have no concern about the code quality. No, the problem is not that N days aren't given for QA. If the product managers talk to the engineers, they will get a sense of the problem. If they work as colleagues they will be in this sort of discussion all the time. When a product is implemented, they'll keep talking, and they'll be aware that the major corners are being cut, and they'll understand that that puts it at risk. Then they can make better decisions to avoid this. If they have that information and still make the wrong decisions, then they have perverse incentivizes or are behaving maliciously to the business. And if they try to reduce the intuition and professional opinions of their engineering team to some numbers -- estimates, QA lead times, bug counts -- which are pitched over the wall, badly summarizing actual expertise -- then they will fail, badly, over time, because that is a nonsensical way to work. Good decision-making and leadership, imo, don't need you to have found ways to quantify things, and your time is often better spent doing good work than waiting for things to be put into numbers. Quantification helps, sometimes. "If it isn't measurable, how can you make the needed changes? " Doesn't that question sound absurd? You make the needed changes! What does measurability have to do with it?
  • lkrubner 5y ago
    I strongly agree. I wrote something similar here: https://demodexio.substack.com/p/a-master-craftsman-will-have-intuitions?justPublished=true https://demodexio.substack.com/p/a-master-craftsman-will-hav...
  • freetinker 5y ago
    Strongly agree. Another issue with the measurement cult: Goodhart's Law. https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
  • IanCal 5y ago
    I'll take the opposite view here, mostly because I think it's an interesting issue and don't know where I fall on it. If you can't measure the difference, how do you know you've helped? Or if you've made it worse? > "If it isn't measurable, how can you make the needed changes? " Doesn't that question sound absurd? No, because you're saying something is needed with no observable difference when it's changed. If you can't in any way measure the difference between action and inaction, isn't that equivalent to saying "my action is indistinguishable from inaction"? If someone said "I've fixed the bug, no tests changed and you won't see a difference in the reported issues but it's fixed" how confident would you be that they've actually fixed it? How do you trust their changes are needed?
• muzani 5y ago
  It sounds like "Because our teams are not given n days for quality assurance before feature delivery" is just a further Why down. I can see how this becomes a loop if someone isn't trying to get a real answer though.
• inopinatus 5y ago
  If you believe a values problem isn't actionable, you're not thinking for the long term. It's the foundation of strategy.
• 8note 5y ago
  "we don't have a method to prioritize code quality"