3 ms·
I think it would be wrong to set such a hard rule. You may have a bug which you could fix in say 2 hours but refactoring the code as a whole take 5 days. Is it
by tuwtuwtuwtuw 6y ago
I think it would be wrong to set such a hard rule. You may have a bug which you could fix in say 2 hours but refactoring the code as a whole take 5 days. Is it always the "grownup" way to tell the customer that they can't use the system the next 3 days? I think it sometimes makes more sense to fix the code as is and then schedule a refactoring.
- hinkley 6y agoMastery is not about learning the rules from a book. It’s about learning the rules that no one wrote down, and about learning which things that were written down aren’t rules so much as guidelines. (This is the exact story arc of probably 30% of all martial arts movies). The quick hacks are quick. That’s why they are so addicting. You have to look at the bigger picture. Is this the third time you’ve used the same quick fix? Then there’s a deeper problem. Does this problem keep happening in production? Then it’s better to take a breath, fix it correctly and once and for all, rather than to be randomly pre-empted by this issue for years to come. Those liabilities stack up, and eventually form clusters that make us look like we can’t do the job. And last but not least, does this person really keep their promises to come back and fix things later, or is it just pretty words? If Cat Stevens were a coder, he’d write a song about all the someday lies developers tell themselves and each other. Father-son neglect dynamics have nothing on code rot.