4 ms·
There is a very fine line between "good enough" and "not good enough" in any product beyond a certain complexity. Finding the pieces that cross that line can be
by gmueckl 2y ago
There is a very fine line between "good enough" and "not good enough" in any product beyond a certain complexity. Finding the pieces that cross that line can be hard and improving "good enough" parts is (sadly) mostly a waste of time in commercial settings.
- hinkley 2y agoYou have to backdate starting a project so it happens before things stop being good enough. And take into account bad estimates and the five other deadlines between then and now. Often it’s better to clean as you go. If you have the time and the inclination, shore up one of the least good enough things. It’s not unheard of to open up new feature sets via refactoring. Something that previously would have taken an “impossible” amount of time now becomes profitable, not just possible.
- dmorgan81 2y agoI miss working at a place where that was encouraged. Now if I do that the testers complain that it’s not in scope for the ticket and to split the changes into another ticket with a separate test plan. The rot thus continues.
- hinkley 2y agoI think this is about when I discovered zone defense for performance optimization. QA doesn’t want to chase your code changes halfway across the codebase, and that’s fair. At some point it starts looking like you’re changing things just to change them, even if it ends up being a few percent better. But if you limit yourself to one part of the interaction, they don’t get as mad. A dozen changes in the signup system piss them off less than five changes across the app.
- didgetmaster 2y agoThis is why some bugs never get fixed (that is if you define a bug to include inefficient code and not just code that breaks something).