4 ms·

I think what was missing here was lack of developer buy-in into the actual changes implemented, and making sure that they were reasonable and sustainable. Sound

I think what was missing here was lack of developer buy-in into the actual changes implemented, and making sure that they were reasonable and sustainable. Sounds to me like a blanket mandate was handed out without buy-in and also wasn't achievable, and the developers felt they had to work around it to get their real jobs done.

bumby 3y ago
I agree. At the very least, it seems like he didn't communicate the "why". It certainly wasn't "to make as many tests as possible". I suspect the developers knew that, which is why is also a little unprofessional on their part to treat it like that was the goal.
- nicoburns 3y ago
  I think the bigger problem here was inappropriate expectations: "two tests a day". That's not a reasonable way to increase test coverage. And so the developers quite reasonably just tried to minimise the time spent on it.
  - bumby 3y ago
    >Number of unit tests isn't the best proxy for that goal… However, I don’t think mindlessly creating tests is acting in good faith. It’s bordering on malicious compliance. I doubt they were thinking they can just knock out that metric so they can otherwise create better test coverage. (The OP conceded their coverage wasn’t good). Better employees would work to create a better understanding/goal. All of that points to some cultural problems.
    - frollo 3y ago
      Malicious compliance is exactly what you get when people think your target is stupid and you put some automated, non-negotiable measurement in place. If I was a developer there, I'd totally started adding those generated tests. I have a job to do (ship products) and you put in some stupid requirements which actually interfere with it (since my time is limited I can either work on tests or my daily tasks like developing new features or fixing bugs), but we both know that if my primary job suffers, I'll pay for it. So the best solution, from my point of view, is the one that takes that requirement away and lets me go on actually working. When we had a similar problem in a previous company, we just created an epic, assigned a couple of people to it and have them churning out tickets for specific improvements, like "Class X has a coverage of Y on this method, add tests for the missing execution branches", which were clear, non-generic and fully integrated in our flow. If anybody complained about our velocity or whatever, we could show them the full trail which lead us to choose to work on that ticket and how much we spent on it. The coverage issue got solved in less than a month.
      - bumby 3y ago
        >If I was a developer there, I'd totally started adding those generated tests. If I were a manager there, I probably wouldn’t hire you. You want people who are actively solving problems that matter, not just automatons beating their chest about how stupid everyone else is while they add to existing problems.
        esyir 3y ago
        If I was a dev there, I certainly wouldn't be approving those PRs either. But if the devs at the org all (or even substantially) tend towards malicious compliance, that's a sign that something has gone wrong, relations-wise
        bumby 3y ago
        Agree. That’s what I mean when I say it’s more indicative of cultural issues.
        frollo 3y ago
        I you were a manager there and would approve that metric, no worries, I'd manage to fly it past you. Any smart manager, having to deal with this kind of policy, would either push back or approve any way to game it and then get the work done. But I doubt that a company which allows this kind of BS can retain smart managers for more than a couple of months.
        bumby 3y ago
        If you read any of my posts on this thread, it’s pretty obvious I don’t agree with the managers approach. But I also don’t agree that the devs are doing the right thing either. It’s telling that you show such dichotomous and defensive thinking.
        frollo 3y ago
        So you disapprove of the decision, but would have enforced it in the most asinine way at the expense of actual productivity. I just hope to never work with you and, especially, never use anything you helped building.

bumby 3y ago

I agree. At the very least, it seems like he didn't communicate the "why". It certainly wasn't "to make as many tests as possible". I suspect the developers knew that, which is why is also a little unprofessional on their part to treat it like that was the goal.

nicoburns 3y ago
I think the bigger problem here was inappropriate expectations: "two tests a day". That's not a reasonable way to increase test coverage. And so the developers quite reasonably just tried to minimise the time spent on it.
- bumby 3y ago
  >Number of unit tests isn't the best proxy for that goal… However, I don’t think mindlessly creating tests is acting in good faith. It’s bordering on malicious compliance. I doubt they were thinking they can just knock out that metric so they can otherwise create better test coverage. (The OP conceded their coverage wasn’t good). Better employees would work to create a better understanding/goal. All of that points to some cultural problems.
  - frollo 3y ago
    Malicious compliance is exactly what you get when people think your target is stupid and you put some automated, non-negotiable measurement in place. If I was a developer there, I'd totally started adding those generated tests. I have a job to do (ship products) and you put in some stupid requirements which actually interfere with it (since my time is limited I can either work on tests or my daily tasks like developing new features or fixing bugs), but we both know that if my primary job suffers, I'll pay for it. So the best solution, from my point of view, is the one that takes that requirement away and lets me go on actually working. When we had a similar problem in a previous company, we just created an epic, assigned a couple of people to it and have them churning out tickets for specific improvements, like "Class X has a coverage of Y on this method, add tests for the missing execution branches", which were clear, non-generic and fully integrated in our flow. If anybody complained about our velocity or whatever, we could show them the full trail which lead us to choose to work on that ticket and how much we spent on it. The coverage issue got solved in less than a month.
    - bumby 3y ago
      >If I was a developer there, I'd totally started adding those generated tests. If I were a manager there, I probably wouldn’t hire you. You want people who are actively solving problems that matter, not just automatons beating their chest about how stupid everyone else is while they add to existing problems.
      - esyir 3y ago
        If I was a dev there, I certainly wouldn't be approving those PRs either. But if the devs at the org all (or even substantially) tend towards malicious compliance, that's a sign that something has gone wrong, relations-wise
        bumby 3y ago
        Agree. That’s what I mean when I say it’s more indicative of cultural issues.
      - frollo 3y ago
        I you were a manager there and would approve that metric, no worries, I'd manage to fly it past you. Any smart manager, having to deal with this kind of policy, would either push back or approve any way to game it and then get the work done. But I doubt that a company which allows this kind of BS can retain smart managers for more than a couple of months.
        bumby 3y ago
        If you read any of my posts on this thread, it’s pretty obvious I don’t agree with the managers approach. But I also don’t agree that the devs are doing the right thing either. It’s telling that you show such dichotomous and defensive thinking.
        frollo 3y ago
        So you disapprove of the decision, but would have enforced it in the most asinine way at the expense of actual productivity. I just hope to never work with you and, especially, never use anything you helped building.