Do you remember Jenga? You can still buy the game now, but it doesn’t have the same impact it did “back in the good old days.” Smartphones, gaming consoles, and the rise of personal computers have all hurt the game industry. But, hey, apparently the game is apparently making a comeback.
Now let’s take IT for a second. (Don’t worry, we’re going to get back to Jenga in a minute.)
There is the concept of “technical debt.” Techopedia describes it as:
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.
So, if you had the time to do it right, you would have come up with a better solution than the one that you implemented. It sounds like almost every project out there doesn’t it?
Technical debt is like Jenga in that the more changes (turns) you make, the more the overall application (stack of bricks) becomes unstable. You can keep making changes. but at some point. it is going to fall. We have applications that are in this condition right now, where we have piled change after change after change, all of them done in relative haste and all of them adding to the technical debt of the system.
It is taking longer to introduce the simplest of changes and therefore costing more money. It will soon come to the point where the money we pour into the applications is not even enough to keep it functioning properly.
The solution, however, is not something that people want to hear: throw it away.
Yup, those solutions that cost a ton of money? Sometimes you have to bite the bullet and start from scratch. Throwing it away doesn’t mean that you throw away the data, but you throw away the application and build something fresh, something new and something free of that technical debt.
How do you prevent the technical debt? You can’t. You will always have technical debt, but you can work to keep it minimized. If you have a solid architecture, solid principles around which you develop, you will accumulate technical debt much more slowly, and you can proactively work at keeping that debt minimal. See Refactoring.
The hardest part of all this is not understanding that you have technical debt or even the architecture and standards involved in minimizing and reducing it. The hardest part of the whole process is letting go of the existing system, understanding that the tower is falling and that you need to have something in its place before it comes crashing down.