November 23, 2015 at 12:00 am
Comments posted to this topic are about the item Technical Debt
November 23, 2015 at 12:44 am
Technical debt is one of those problems that is just gets worse the more it is ignored. If it isn't considered then what tends to be produced is far worse than otherwise would be. And if it is never dealt with then the complexity of s source code base becomes so high that most changes are extremely expensive.
I personally commend the sprint to deal with technical debt.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 23, 2015 at 3:07 am
Totally agree with Gaz! The last two major products I have worked on have had major technical debt so that an simple mod or bug fix runs into days or even weeks instead of a few hours or a day, or two, as vast chunks of code are unclear and comments (in the code) like "I must sort this out one day" far from helpful!
Annoyingly a project I worked on a decade ago could have had much of the technical debt sorted out but instead had endless false starts on enhancements/upgrades that were then pulled. It was quite demoralising to spend months developing a reporting package in 'Crystal Reports' to have the plug pulled two weeks from completion!
November 23, 2015 at 4:43 am
Technical dept, if not handled soon, will cause issues and unwanted compromises down the road.
...until I was looking for a feature to be completed and the technical debt train was running that week. I thought about complaining, but I decided to have patience and wait a week.
Exactly, what kind of new feature cannot wait a week longer! We often get chased to finish something super urgent, take shortcuts to achieve it, just to find out that the requester of this feature will be on holiday the next month and nobody will test it!
November 23, 2015 at 6:49 am
Currently dealing with technical debt in a product that the development team refuses to recognize since they don't deal with the management/maintenance of databases once in production. A true case of throw the code over the wall.
:angry:
So it's up to me to write the utilities and documentation that allow my team and the clients to fix short comings in the products design and coding. Color me cynical blue.
:crazy:
November 23, 2015 at 6:52 am
In upper management speak 'technical debt' has no value add. The code works so what's the point in spending time aka money on it?
The real trick is to get upper level buy in to clean up the code base. The easist and least obvious way is to budget extra time when doing enhancements to the code that requires it. That way it doesn't show up in discussions and it gets done.
It's not the most transparent way to go about it but it's one way to slip it into the schedule and make a start.
You might not be able to get all of it in one pass but any is better than none.
November 23, 2015 at 6:58 am
JustMarie (11/23/2015)
...The easist and least obvious way is to budget extra time when doing enhancements to the code that requires it. That way it doesn't show up in discussions and it gets done.It's not the most transparent way to go about it but it's one way to slip it into the schedule and make a start.
You might not be able to get all of it in one pass but any is better than none.
Arguably, this is part of the cost of change in order to keep maintainability which the management do not want to see the cost of but they do want to reap the rewards from.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 23, 2015 at 9:17 am
liebesiech (11/23/2015)
Technical dept, if not handled soon, will cause issues and unwanted compromises down the road....until I was looking for a feature to be completed and the technical debt train was running that week. I thought about complaining, but I decided to have patience and wait a week.
Exactly, what kind of new feature cannot wait a week longer! We often get chased to finish something super urgent, take shortcuts to achieve it, just to find out that the requester of this feature will be on holiday the next month and nobody will test it!
While I agree on the fact that most things can wait some time, when it takes a week to do a feature that might take a day or two with better code, you also have more and more requests that stack up. That leads to less and less getting done, especially from the perspective of the client. That's not a good situation, long term.
November 23, 2015 at 9:20 am
JustMarie (11/23/2015)
In upper management speak 'technical debt' has no value add. The code works so what's the point in spending time aka money on it?The real trick is to get upper level buy in to clean up the code base. The easist and least obvious way is to budget extra time when doing enhancements to the code that requires it. That way it doesn't show up in discussions and it gets done.
It's not the most transparent way to go about it but it's one way to slip it into the schedule and make a start.
You might not be able to get all of it in one pass but any is better than none.
I like to use the analogy for vehicles. An oil change has no value add. It takes something out of service, and it costs. However it's a way of ensuring that you have more reliability in the future and can get things done when you need them.
Reducing technical debt is one of those things that is likely easy if you have good developers that want clean code, and you allow them some time to work. It also helps to have good testing in place to be sure they don't break something.
November 23, 2015 at 9:22 am
Quoting from your article:
However the suggestions given require some discipline and buy in from management...
Getting management buy in is for me one of the most crucial things of all of this. Many is the time that I and others in the IT staff have argued to get something done right, only to be told to put it on hold so that the latest crisis could be done instead, and often in a rush, thus adding to more technical debt.
Kindest Regards, Rod Connect with me on LinkedIn.
November 23, 2015 at 9:26 am
Steve Jones - SSC Editor (11/23/2015)
...I like to use the analogy for vehicles. An oil change has no value add...
Yes. Great analogy. Something that is essential yet does not improve things from an external point of view.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 24, 2015 at 2:11 am
Steve Jones - SSC Editor (11/23/2015)
liebesiech (11/23/2015)
Technical dept, if not handled soon, will cause issues and unwanted compromises down the road....until I was looking for a feature to be completed and the technical debt train was running that week. I thought about complaining, but I decided to have patience and wait a week.
Exactly, what kind of new feature cannot wait a week longer! We often get chased to finish something super urgent, take shortcuts to achieve it, just to find out that the requester of this feature will be on holiday the next month and nobody will test it!
While I agree on the fact that most things can wait some time, when it takes a week to do a feature that might take a day or two with better code, you also have more and more requests that stack up. That leads to less and less getting done, especially from the perspective of the client. That's not a good situation, long term.
Agree and it depends probably also on the industry you are in and if your users are external or internal clients. Knowing my industry (reinsurance) for over 20+ years, there is generally nothing so urgent that it cannot wait for a week unless it is a bug fix during quarterly closing.
November 24, 2015 at 6:36 am
I've never heard of putting time in for this in a project but we have talked here in IT about the subject, just not calling it Technical Debt. I think it is a great idea.
July 31, 2019 at 8:54 am
Typo?
"Certainly the more debt that piles up, the mode (more?) difficult it can be to change code. "
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply