2 Responses

  1. Andy Konecny
    Andy Konecny at |

    “Technical Debt” is a wonderful term, and there are many times where it is actually more economical to pay it rather than what can be a huge redevelopment cost.
    Once upon a time 16-bit apps were THE way to go, in part because “640K ought to be enough for anybody” as said by Bill Gates(in his full marketing mode). And there are still many such applications still existing because they do the job they need to do, and any amount of messing with it (aka “upgrades”) only risks stopping it from doing the job needed.
    As one set of ‘Best practices’ gets replaced by the next iteration of ‘best practices’ (sometimes even radically so on the same generation of a product), systems are designed and built in good faith under the ‘best practices’ of the time. This doesn’t make them bad designs, nor invalidates the tasks they are accomplishing. The ‘upgrade’ to the current ‘best practice’ usually has a high cost that in many cases doesn’t improve the system’s ability to do the tasks they were created for, resulting in a huge negative ROI.
    For the most part, that blame game is rather silly, though the vendors do invite it upon themselves. When the vendor PUSHES the upgrades too hard, it is natural push back for the existing systems are working just fine. Take a corporate back end 32-bit(or even 16bit) application that is working just fine. In many cases it is just easier and most cost effective to keep it running on the operating environments it was designed for, and simply build the new systems on the new ways of doing things.

    Reply
  2. JC
    JC at |

    Change just because everyone else is doing it? Didn’t your mama ever teach you about friends and jumping off of bridges? In the manufacturing world, change occurs when the risk to not change exceeds the risk to change OR the new TCO is less than the old TCO so that the payback pays for the system in less than 24 months.

    Reply

Share your point of view!