3 ms·

Ugh. This mentality is fine when you want to ship an MVP but it's absolutely poisonous to the team and the project if you hold on to it. You need some slack f

by oddity 5y ago

Ugh. This mentality is fine when you want to ship an MVP but it's absolutely poisonous to the team and the project if you hold on to it. You need some slack for people to address the problems they think need solving without needing to justify why they're solving it. From a team perspective, it helps prevent burnout and encourages development, and from a project perspective it's essential to preventing management-driven tunnel vision by allowing the team to explore and prove out things that management doesn't understand yet. I've seen a lot of data-driven projects starve because of a fear of collecting new data, and it's totally invisible to management because they're hitting the KPIs they set for themselves. Prioritize, yes, but don't starve lesser priorities. Let individuals decide, say, 10%-20% of their effort spend and don't question it. That figure, conveniently, corresponds to the Friday they're spending not productively working anyway.

cogman10 5y ago
Yup, it's precisely this narrow minded view of software development that's churning out more and more shitty software. Maintenance is NEVER prioritized by anyone in management. They think "What, we put in the bug fixes, what more do you want!" but they never put in the "Hey, if we reorganize some code here, things will be a lot faster and easier to extend". Devs on the ground can consistently see "Hey, this system right here, is a major issue that'll cause us a bunch of problems in the future" and that does not matter. Because, quantifying how much money is lost by not fixing the issue is really hard to do. You can't reliably say "If I spent 10 hours fixing this, I'd save 100 hours implementing new features". It's this sort of short sighted vision that has dev teams running on 20 year old software with a bunch of known CVEs, handcuffed because the answer to "What will upgrading to the latest bring us?" is almost always "some bugs in transition but mostly piece of mind that we won't be vulnerable to a cyber attack."
- deleted 5y ago
  [deleted]
- oddity 5y ago
  Oh I wish avoiding code cleanup was the worst of it. I've seen people totally ignore the most easily fixable bugs. Everyone knew what they were and how to fix them, but no one wants to be that person who spent time working on the bug that was only affecting 5% of users if it meant that any of the bugs that were affecting 95% of users were even a day later. Ignoring the ROI, the fact you even need to have that conversation adds cost. Where it becomes more insidious is in planning for broader efforts, where even the ROI is nebulous. People seem hesitant to invest in experimenting to estimate ROI, which limits the topics and questions teams even bother to ask and gives a very skewed, short-sighted view to management.

by oddity 5y ago

cogman10 5y ago

Yup, it's precisely this narrow minded view of software development that's churning out more and more shitty software. Maintenance is NEVER prioritized by anyone in management. They think "What, we put in the bug fixes, what more do you want!" but they never put in the "Hey, if we reorganize some code here, things will be a lot faster and easier to extend". Devs on the ground can consistently see "Hey, this system right here, is a major issue that'll cause us a bunch of problems in the future" and that does not matter. Because, quantifying how much money is lost by not fixing the issue is really hard to do. You can't reliably say "If I spent 10 hours fixing this, I'd save 100 hours implementing new features". It's this sort of short sighted vision that has dev teams running on 20 year old software with a bunch of known CVEs, handcuffed because the answer to "What will upgrading to the latest bring us?" is almost always "some bugs in transition but mostly piece of mind that we won't be vulnerable to a cyber attack."

deleted 5y ago
[deleted]
oddity 5y ago
Oh I wish avoiding code cleanup was the worst of it. I've seen people totally ignore the most easily fixable bugs. Everyone knew what they were and how to fix them, but no one wants to be that person who spent time working on the bug that was only affecting 5% of users if it meant that any of the bugs that were affecting 95% of users were even a day later. Ignoring the ROI, the fact you even need to have that conversation adds cost. Where it becomes more insidious is in planning for broader efforts, where even the ROI is nebulous. People seem hesitant to invest in experimenting to estimate ROI, which limits the topics and questions teams even bother to ask and gives a very skewed, short-sighted view to management.