The cost of debt
Any financial adviser will tell you that debt has costs. The cost of interest is the biggest and most obvious one.
Technical projects have debt as well. "Quick and Dirty gets it done", "Deadline Rules" and "We'll fix that in the next release" are but three of the refrains common to almost any technical project. At times, they have their place. It would be foolish to postpone a major "go-live" to change the structure of an index and the lost revenue could collapse the viability of the program.
However, too many times, "putting off til tomorrow", becomes "let the new guy/gal/team worry about it" because of staffing turnover or because the development team and the maintenance teams are in different departments. This maintenance is the technical equivalent of interest in the financial realm.
This blog post is a great read and should be mandatory for all IT managers involved in development or maintenance projects. Jeff explains why shortcuts today can cripple a business in the future. He is not so idealistic to expect that shortcuts will not be sometimes necessary to meet a business requirement, but suggests that some resources need to be budgeted to periodically fix these. I have personally butted heads with several managers over this very issue and have been frustrated in some jobs because there was no willingness to do ANY development that was not directly related to new features or bug fixes.
Consider a company in year 3 of a 7 year plan to move all of their applications off of a specific platform. What percentage of their applications had been moved? Should be close to 50% if it was evenly spread over 7 years right? Sadly, it was 0% and the only activity towards the goal was that most (but not all) of the new projects were being developed on the new platform.
The cost of their technical debt in this case became evident when they had a staff reduction to reduce costs. If the old (expensive) platform decommissioning had been on schedule, the net savings would have likely been more than the salary costs saved by staff reductions. Sadly, now with less people (and some very experienced key team members gone) this project has even less of a chance of success. It is a vicious cycle, like someone with too much debt who is no longer able to make even the interest payments on their debt who will have a large battle to get out of debt or face bankruptcy.
Don't let your company face technical bankruptcy!
Technical projects have debt as well. "Quick and Dirty gets it done", "Deadline Rules" and "We'll fix that in the next release" are but three of the refrains common to almost any technical project. At times, they have their place. It would be foolish to postpone a major "go-live" to change the structure of an index and the lost revenue could collapse the viability of the program.
However, too many times, "putting off til tomorrow", becomes "let the new guy/gal/team worry about it" because of staffing turnover or because the development team and the maintenance teams are in different departments. This maintenance is the technical equivalent of interest in the financial realm.
This blog post is a great read and should be mandatory for all IT managers involved in development or maintenance projects. Jeff explains why shortcuts today can cripple a business in the future. He is not so idealistic to expect that shortcuts will not be sometimes necessary to meet a business requirement, but suggests that some resources need to be budgeted to periodically fix these. I have personally butted heads with several managers over this very issue and have been frustrated in some jobs because there was no willingness to do ANY development that was not directly related to new features or bug fixes.
Consider a company in year 3 of a 7 year plan to move all of their applications off of a specific platform. What percentage of their applications had been moved? Should be close to 50% if it was evenly spread over 7 years right? Sadly, it was 0% and the only activity towards the goal was that most (but not all) of the new projects were being developed on the new platform.
The cost of their technical debt in this case became evident when they had a staff reduction to reduce costs. If the old (expensive) platform decommissioning had been on schedule, the net savings would have likely been more than the salary costs saved by staff reductions. Sadly, now with less people (and some very experienced key team members gone) this project has even less of a chance of success. It is a vicious cycle, like someone with too much debt who is no longer able to make even the interest payments on their debt who will have a large battle to get out of debt or face bankruptcy.
Don't let your company face technical bankruptcy!
Comments