August 15, 2022 at 12:00 am
Comments posted to this topic are about the item Reducing Debt and Increasing Security
August 15, 2022 at 1:54 pm
Technical debt is a topic I am very interested in. Where I work we have a large amount of technical debt. It might simply be due to the fact that this is the largest IT group I've ever worked in, so perhaps percentage wise it isn't any worse than any other place.
But what does surprise me is the lack of effort to fix the technical debt we have. Unless an application isn't working or is producing blatantly false information, nothing is really done about technical debt. It just continues to accumulate. And it isn't because we're following an Agile or DevOps methodology of releasing quickly. Far from it. We release remarkably slowly, with either months or possibly years before a big bang release. However, when something has technical debt in it (not everything has technical debt), rather than remove the technical debt, it is just patched ad infinitum.
Kindest Regards, Rod Connect with me on LinkedIn.
August 15, 2022 at 5:38 pm
Rod, I'm not surprised that your large IT organization has this problem. In my experience, the larger a group is, the harder it is to address debt. (If it was just you, you could decide to work on it.)
I've pointed this out to my management and the most successful approach I've found is to try to bundle some refactoring into the "definition of done" of our larger projects. We'll add feature set X and also correct debt Y in this project. Doesn't always fly, but it has a better chance than adding a month and a half to a two week project.
Besides security, we also like to focus on eliminating one-off technology. "That module is the only one using the Z library, and Harry is the only one who knows it." That's a risk we should address, (and sometimes a money savings if we're licensing Z for just this purpose).
August 15, 2022 at 8:52 pm
It requires a mindset that looks long term, not this quarter or year. You have to think that we want to be able to adjust and easily fix our code across years, which means we can't get burdened down by too much debt to the place where a rewrite starts to make sense. We want to be cleaning code as we can. Even if it's a 5-10% of our time project.
August 16, 2022 at 1:31 pm
Rod, I'm not surprised that your large IT organization has this problem. In my experience, the larger a group is, the harder it is to address debt. (If it was just you, you could decide to work on it.)
I've pointed this out to my management and the most successful approach I've found is to try to bundle some refactoring into the "definition of done" of our larger projects. We'll add feature set X and also correct debt Y in this project. Doesn't always fly, but it has a better chance than adding a month and a half to a two week project.
Besides security, we also like to focus on eliminating one-off technology. "That module is the only one using the Z library, and Harry is the only one who knows it." That's a risk we should address, (and sometimes a money savings if we're licensing Z for just this purpose).
Larry, thank you for suggesting that approach of getting management's buy in by saying we can refactor some technical debt in at the same time as finishing another project. And thank you for pointing out the challenges you've experienced while using that strategy. An occasional win is better than never having a win.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply