21–30 of 92 posts
Earlier quoted context omitted.
Yes, but every other feature will take ten times as long as over the next three years we will lose 90% of our best developers.
"This is the last feature we will tell you to rush, we promise. We really need just this one, and then we're good."
RAII your technical debt: make a note of every time you slap something together the expedient way, and schedule a future time to refactor after the legitimacy of expediency goes "out of scope", e.g., after a major product demo. One could even add a CI/CD task to remind the user of when refactorings are due (and refuse to successfully build until they are addressed). Since debt is created by borrowing, one could call…
Earlier quoted context omitted.
Yes, but every other feature will take ten times as long as over the next three years we will lose 90% of our best developers.
"This is the last feature we will tell you to rush, we promise. We really need just this one, and then we're good."
The reason is that I can atleast somewhat justify the changes under the umbrella of my feature while utilizing the allocated time budget. If I don't do this, we will never get a dedicated release to do tech cleanup - the backlog of feature requests is just too big and too little appetite on the decision makers' side for purely tech debt releases.
Earlier quoted context omitted.
"I'm sorry, I didn't understand much of that. Are you saying you can commit to finishing the feature on a shorter timeframe than you originally asked for? Would it help if we forgo writing tests?"
Yes, but every other feature will take ten times as long as over the next three years we will lose 90% of our best developers.
True story. Twice.
> Building software iteratively leads inevitably to tech debt because we choose to deliver systems before we have looked at all the requirements. Not knowing what’s next distorts our designs, and that distortion is the tech debt. This article frames technical debt as something that happens passively because you can't know future requirements. That's sometimes true, of course, but in my experience the majority of tech…
I've been on teams like that and it's absentee management. There's two reasons: the management is technically inept or the execs and other stakeholders are taking up too much of their time. Sometimes it's both.
This creates a situation where either the most technically competent team member takes over responsibilities or the team just loses coherence.
Beyond that there's also often a severe lack of involvement from the broader organization where everything is siloed.
The quality of the dev team reflects the quality of the business. Implementation details are not so different from "operations" in other fields. Makes no sense we have such a terrible state of things in software at some places other than a lack of talent and residual people who should have retired or pivoted careers a long time ago.
I do opportunistic collection - when I am working on a feature, and spot opportunities for a refactoring/cleanup in code that is more or less directly related to the code I'm touching, I will keep making small incremental changes and keep testing them until my feature is implemented and the cleanup is done as well. I also ensure to not make a breaking change while doing this e.g. no change to the user facing api sign…
I do opportunistic collection - when I am working on a feature, and spot opportunities for a refactoring/cleanup in code that is more or less directly related to the code I'm touching, I will keep making small incremental changes and keep testing them until my feature is implemented and the cleanup is done as well. I also ensure to not make a breaking change while doing this e.g. no change to the user facing api sign…
“Why did you do this refactor with the feature? Can you pull the feature into another PR, then we’ll leave the refactor in the original PR to be merged at another time? (read: never)”
RAII your technical debt: make a note of every time you slap something together the expedient way, and schedule a future time to refactor after the legitimacy of expediency goes "out of scope", e.g., after a major product demo. One could even add a CI/CD task to remind the user of when refactorings are due (and refuse to successfully build until they are addressed). Since debt is created by borrowing, one could call…
A couple times I've put a "if (now() > xxxxxx) fail()` in tests for this reason.