Comments by "disgruntledtoons" (@disgruntledtoons) on "Types Of Technical Debt And How To Manage Them" video.

  1. The part of our code that is holds a high proportion of technical debt is a module that was put together by a contractor, using a coding framework. It goes without saying that this one reason why code frameworks should be avoided; they allow the quick development of a new application of major feature, but code maintenance becomes far more difficult; unless the framework designers envisioned any desired extension or behavior when developing the framework, there is a good chance that the extension cannot be added at all, and a high chance that the time it will take will be greater than if the framework had not been used. Frameworks only increase the number of things that have to be learned in order to get any real work done. A lot of software shops inflict unnecessary technical debt by establishing deadlines for the completion of a change. All such deadlines are based on wishful thinking. Every program or code module, while it is being written, is being written for the first time. Any guess about how long it will take is a guess, which can be wrong. In many instances the deadline is entirely unnecessary. If the new feature is being developed to make the product more appealing to prospective customers, and not to address the needs of existing customers, there is no need to inform anybody that it will be ready by a given time, and no reason to inform the customers that the feature is forthcoming. Wait until the new feature works as advertised, has survived all efforts to break it, and its place in the application is fully documented; then announce the feature to the world. The only technical debt consists of the bugs that got past QA (and there will be fewer of those). Re-factoring can be done by baby steps, but it requires vision and perseverance. Instead of making a small change, testing it to make sure that it doesn't break anything, and then pushing it to the production branch, managers often want a developer to keep everything for a new feature in a separate branch until it is all ready to go, and then merge it into production. The risk and cost of each change is not linear with the size of the change, and so the huge merge is very costly it time. I've suggested doing major changes by small steps, but my supervisor shot this down because if the project is cancelled then it will take time to revert all of the changes; but should cancelling projects be common enough to warrant such concern? Also, managers are often too afraid that a change will break things. If the fear is real, why hasn't the head of QA been sacked?
    1