Do you devote scrums/iterations for technical debt? If so, how often?
What do you consider to be technical debt?
Do you devote scrums/iterations for technical debt? If so, how often?
What do you consider to be technical debt?
For further actions, you may consider blocking this person and/or reporting abuse
Kelvin Hey -
Vinod Kumar -
Buzzpy 💡 -
Shafayet Hossain -
Top comments (4)
Here at Liferay many teams do this. I, personally, do not like it. What I used to do was to create tickets for every change I'd like to see. Then, when that technical debt made some story or bug hard to process, I'd then fix the technical issue as part of the story and bug.
It was nice because:
I guess Ron Jeffries gives a good explanation of what I think is a better approach to technical debt.
Ron Jefferies article seems very good. First time I read that one.
For me and where I work it is kind of a case by case basis. Sometimes if it is a small scope change we will simply make the change and do a full regression. For bigger changes it usually requires more planning and meetings to determine if we can make the change within our schedule.
As far as what technical debt is, well it is simply code that is hard to maintain and add new features to. One perfect example for my company is a web page where the user can enter a lot of different data and select many options resulting in something like 50 million combinations of options. The way this code is written means that if more than 1 person works on it there is pretty much guaranteed to be horrible merge conflicts, incompatibilities, and hidden edge case bugs that can only get found in production. This wastes a lot of time and makes maintenance difficult.
On past jobs/projects we (me and the team, if any) never really cared about technical debt nor had a process to take care of it.
On my current project, the only technical debt we (me and the project manager) care about is the one reported by our code inspection tool (SonarQube). I usually have a look at it when I have time (usually a bit before the end of a sprint) and try to fix as much as I can. That's a very small scale project so that works for us.