4 ms·

Developer efficiency is actually harmed by valuing it so much. Developers get into pointless ideological debates about purity and that hurts their efficiency. W

Developer efficiency is actually harmed by valuing it so much. Developers get into pointless ideological debates about purity and that hurts their efficiency. When good developers have to deliver features in a short time frame they stop debating that stuff and make decisions. They then learn from these decisions the hard way and no one is having an ideological debate any more.

wslh 6y ago
Yes, indeed it is team efficiency.
majormajor 6y ago
There's a "no true scotsman" answer where both these ideological debates, and the "ship a bad experience because the developer wants to use shiny technologies" the original article discusses, are clearly not ultimately "efficient" for the business. But it points to a problem with using the word "efficiency" like this if it's so commonly misused/misinterpreted. "Deliver value" is something I've seen people push instead, and it tends to stay more customer-focused. It's hardly perfect, and there are still temptations to bikeshed and focus on the wrong thing, but it's a bit easier to recognize and course-correct as a team when that's your ultimate goal.
- a1369209993 6y ago
  > But it points to a problem with using the word "efficiency" like this Just adding faux-numerical terminology helps a bit: ideological debates are of (approximately) zero value, whereas javascript frameworks are of negative value. > "Deliver value" TFA did already make this point, but that's meaningless unless it's short for "Deliver value, even it conflicts with [some specific other thing that you might resonably want to do].".
agentultra 6y ago
And if they keep delivering features in short time frames they will never get a chance to debate quality or elegance in their work. And eventually you will start hearing them complain about an unmaintainable mess and turnover will probably increase. /s I think you do have to care, on some level, about maintaining code quality and standards. I've worked in feature-factories and it's not a panacea. It doesn't crash and it goes reasonably fast are both features after all that seem to be related to the quality of a code base and the expertise of the team behind it.
- jakear 6y ago
  One approach is a schedule for when everyone works on debt vs features vs testing. For instance: first week of the iteration is for paying off debt. Second and third are feature work. Fourth is testing (note: not unit testing, real testing. As in everybody chips in to actually play around with the features their colleagues added and provide feedback; also verify that all the bugs that were fixed this iteration didn’t creep back in, or get fixed with a “works on my machine” patch)
- partyboat1586 6y ago
  Of course there is a balance to be struck. I'm not saying don't plan things out at all. I'm saying limit the time you spend doing it relative to the impact of the decision. That's not always easy to gauge which is where an experienced tech lead comes in to have the final say on what gets done and how long the debate goes on for. A strong tech lead is essential.

wslh 6y ago

Yes, indeed it is team efficiency.

majormajor 6y ago

There's a "no true scotsman" answer where both these ideological debates, and the "ship a bad experience because the developer wants to use shiny technologies" the original article discusses, are clearly not ultimately "efficient" for the business. But it points to a problem with using the word "efficiency" like this if it's so commonly misused/misinterpreted. "Deliver value" is something I've seen people push instead, and it tends to stay more customer-focused. It's hardly perfect, and there are still temptations to bikeshed and focus on the wrong thing, but it's a bit easier to recognize and course-correct as a team when that's your ultimate goal.

a1369209993 6y ago
> But it points to a problem with using the word "efficiency" like this Just adding faux-numerical terminology helps a bit: ideological debates are of (approximately) zero value, whereas javascript frameworks are of negative value. > "Deliver value" TFA did already make this point, but that's meaningless unless it's short for "Deliver value, even it conflicts with [some specific other thing that you might resonably want to do].".

agentultra 6y ago

And if they keep delivering features in short time frames they will never get a chance to debate quality or elegance in their work. And eventually you will start hearing them complain about an unmaintainable mess and turnover will probably increase. /s I think you do have to care, on some level, about maintaining code quality and standards. I've worked in feature-factories and it's not a panacea. It doesn't crash and it goes reasonably fast are both features after all that seem to be related to the quality of a code base and the expertise of the team behind it.

jakear 6y ago
One approach is a schedule for when everyone works on debt vs features vs testing. For instance: first week of the iteration is for paying off debt. Second and third are feature work. Fourth is testing (note: not unit testing, real testing. As in everybody chips in to actually play around with the features their colleagues added and provide feedback; also verify that all the bugs that were fixed this iteration didn’t creep back in, or get fixed with a “works on my machine” patch)
partyboat1586 6y ago
Of course there is a balance to be struck. I'm not saying don't plan things out at all. I'm saying limit the time you spend doing it relative to the impact of the decision. That's not always easy to gauge which is where an experienced tech lead comes in to have the final say on what gets done and how long the debate goes on for. A strong tech lead is essential.