2 ms·
I'm in this camp. I ran into a recent situation where I could have used a drop-in security module if the project had updated the framework in the past decade. I
by Igelau 5y ago
I'm in this camp. I ran into a recent situation where I could have used a drop-in security module if the project had updated the framework in the past decade. Instead we rolled our own, which is janky and took longer than it should have.
Debts have a way of compounding. Tech debt is no exception. Tech debt begets tech debt begets tech debt, and it will hang on your velocity like a ball and chain.
- nlitened 5y agoDedicate 20% of developers’ time on constant updates of all components for a decade just in case you might need one drop-in security module ten years after now (if the company ever lives to see that day)? Does not sound like a good illustrative argument to me, I am afraid.
- chousuke 5y agoBut it doesn't work like that. You might reserve 20% of the time to chores, but you don't have to use all of that 20% every week. Efficiency of maintenance will improve after you get your processes and tooling in order and everyone has had a bit of experience with them, and the leftover time can be used for whatever the developers feel most deserves the extra time. The reason to do maintenance constantly is practice, which makes the difference between taking weeks or days vs. hours. When the time spent is evenly distributed, it's also less likely that an important task would be blocked by unavoidable maintenance.