I've been thinking a lot about technical debt lately. We all have that one piece of code or module that everyone avoids like the plague because it is essentially a big jumble of hacks upon hacks. This isn't that big of a problem if it is a small piece of code that is rarely used, but what do you do if that code is one of the main pieces of your application?
I have been in a situation like this and it is not pretty. That one piece of code turns out to be the most popular for customer requests. The developers know something needs to be done about it, but with all the requests coming in, they are not provided with dedicated time to fix it. So in turn, the time needed to fix the problems increase with each feature. The developers then decide that the time it would take to fix the problem is more than it would take to rewrite the module from scratch so they start down that road thinking they are in the clear. However, they just doubled their work as they must maintain the current module as well. You get the picture...
The moral of this is to avoid the shortcuts that lead to technical debt and if you cannot, do your best to recover the debt ASAP or you will back yourself into a corner.
No comments:
Post a Comment