4 ms·

Thanks for your frank feedback - I do share you POV on the risk of metrics being used for the wrong intentions. Nevertheless I do think that introducing a bug i

Thanks for your frank feedback - I do share you POV on the risk of metrics being used for the wrong intentions. Nevertheless I do think that introducing a bug in CI/CD tests on master (because e.g. you did push directly on master and not on a feature branch, where introducing bugs is fine) is the kind of behaviour that as a manager you want to see reduced. If such things happen, as a CTO I'll anyway ping the dev to let them know they should watch out next time. Delegating this to a simple rules-based engine with rules that everyone agrees on suddenly makes the whole discussion much more objective and avoids human friction. All the while with the more positive cheering which is purely about sharing good stuff. When it comes to actual monitoring of productivity, the current rules don't really allow that, because we all know how hard it is to measure dev productivity (e.g., a single commit of 1 line can add as much value as a big commit of 20 files).

cmeacham98 6y ago
Counterpoint: If a 'bad' action is detectable with a simple rules engine, then it would be more productive to prevent the mistake than automatically chastise the dev about it.
blackbrokkoli 6y ago
If you want people to push to a test branch before master, just set your CI/CD up in a way that enforces this? Build proper infrastructure instead of reinventing the Stasi with more Black Mirror. This is like counting LOC all over again, but worse. As soon as you introduce a metric, (some) people will do anything to win. Make a clique, cheer each other on an hourly base. Introduce a bunch of typos on the about page, tank the penality, fix each one as a separate bug. My points triple whenever I hit 10 green commits? Brb, setting up a background task that checks whether my commit was green and if so deploys it 9 more times. Good use of dev time and resources! Who looses? Your silent wizard dev who could not care less about social gratification and (used to) work on the big picture instead of fixing an endless stream of trivial bugs. I also disagree with the notion that you can/should outsource manager-dev interaction to such a program. If an engine can trivially measure a dev faux pas, it can also just prevent it in the first place. If something unforeseeable goes wrong, you need the "human friction" as you call it. Why? Because you want to actually unroot the root cause (call it 5 Why's or whatever) and not just finger-point someone, and you certainly don't want to tank someone's social score for it. Please look at a database of engineering/software disasters. People die because engineers are dis-incentivised to speak up, challenge security assumptions or break things. Sometimes that includes testing stuff a whole week w/o pushing anything (which you punish) or breaking something (which you punish). Sorry - the idea is well presented and your landing page is nice - but IMO this software somewhere between useless and harmful...

cmeacham98 6y ago

Counterpoint: If a 'bad' action is detectable with a simple rules engine, then it would be more productive to prevent the mistake than automatically chastise the dev about it.

blackbrokkoli 6y ago

If you want people to push to a test branch before master, just set your CI/CD up in a way that enforces this? Build proper infrastructure instead of reinventing the Stasi with more Black Mirror. This is like counting LOC all over again, but worse. As soon as you introduce a metric, (some) people will do anything to win. Make a clique, cheer each other on an hourly base. Introduce a bunch of typos on the about page, tank the penality, fix each one as a separate bug. My points triple whenever I hit 10 green commits? Brb, setting up a background task that checks whether my commit was green and if so deploys it 9 more times. Good use of dev time and resources! Who looses? Your silent wizard dev who could not care less about social gratification and (used to) work on the big picture instead of fixing an endless stream of trivial bugs. I also disagree with the notion that you can/should outsource manager-dev interaction to such a program. If an engine can trivially measure a dev faux pas, it can also just prevent it in the first place. If something unforeseeable goes wrong, you need the "human friction" as you call it. Why? Because you want to actually unroot the root cause (call it 5 Why's or whatever) and not just finger-point someone, and you certainly don't want to tank someone's social score for it. Please look at a database of engineering/software disasters. People die because engineers are dis-incentivised to speak up, challenge security assumptions or break things. Sometimes that includes testing stuff a whole week w/o pushing anything (which you punish) or breaking something (which you punish). Sorry - the idea is well presented and your landing page is nice - but IMO this software somewhere between useless and harmful...