4 ms·

There are multiple cases of "killed by technical debt". There's the case of mysterious and unsolvable breakage. The product simply stops working, and the team

• beat 10y ago
  I should add here that the "antiquation" case is the one that has caused the most observed grief in my career. The forces causing failure are coming from outside the code/business (dependence on an outside vendor), and sometimes collide with forward momentum of other parts of the code (i.e. that graph library will never, ever work with Java 7, to name an example). These become life-or-death situations, and the tendrils of the product dependency are often deeply integrated. It might be easier to rewrite than to fix. Also, this case can impact not just products, but organizations. You can still find teams dependent on an antique commercial version control system or IDE that greatly slows down or even stops work. I've tech-led jumps to new version control systems a few times, and it's always riddled with anxiety, strain, and management angst. (And it always makes the team far happier and more productive!)
  • Arizhel 10y ago
    >You can still find teams dependent on an antique commercial version control system or IDE that greatly slows down or even stops work. Sounds like Rational ClearCase.
    • beat 10y ago
      Yeah, that. But even things like cvs, that were modern and hip in 1998, are still floating around 20 years later. I actually thought Subversion would be the last version control system, when it came out. Of course, now it's git. Maybe someday we'll get something better, and git will look decrepit.
      • Arizhel 10y ago
        I have little doubt that git will be replaced eventually (or perhaps severely modified). It seems like a fad to me. It is indeed very powerful, but its UI is sheer insanity. At least SVN is very straightforward to use and understand. It just doesn't offer the distributed nature that git does, as it relies on a centralized server.
        • pythonaut_16 10y ago
          The cool thing about Git is that the underpinnings ultimately boil down to a key-value data store. I'm not an expert on these innerworkings, but in theory there's nothing stopping someone from creating a new UI that maintains most or all of the same strengths, except that everyone already uses and is used to the current way. I suspect if you came out with "SuperVCS" that was ultimately just a new UI on Git you'd have more success than releasing the exact same project as some kind of Git enhancement.
          • Others 10y ago
            Isn't that basically Gitless? (http://gitless.com/ http://gitless.com/)
        • 10y ago
• koolba 10y ago
  Some of the worst examples of that are when a project uses a custom build of a library of which the source no longer exists and no record of the changes exists either.
  • ayuvar 10y ago
    Reintegrating future changes in the upstream is also made nearly impossible as a result; our tech lead made a change to numpy a few years ago, didn't manage to get it accepted by the project, and we're stuck with this version until the sun burns out. If there are changes in future numpy versions we want, it's up to us to backport them, which is nowhere near our core business. There's a lot to be said for standardization and 'boring.'
    • javajosh 10y ago
      Well you could estimate the impact of backing out of the changes on the application side, with the upside being continued savings in operational complexity. Or, you could address the operational complexity with processes or tooling - which would be easiest with something like a developer OS image.
  • SideburnsOfDoom 10y ago
    Yep, seen that. You might be thinking of tweaked builds of open-source components, but before package managers were so common, I've seen also internal projects with a `/lib` folder full of artefacts like `MiscDbUtils.dll` which are internal "useful" utility functions that are widely used. Now add in a script that updates this artefact with the latest version, breaking changes, and it all goes wrong and it's hard to find the correct previous version of the binary artefact to build your code any more. Especially if the build has been broken for a while due to the project being on the back-burner and it quietly dies when no-one is looking.
  • beat 10y ago
    Builds that involve non-version-controlled files that exist only on a certain developer's machine, and because that developer is a control freak (or overworked), he refuses to automate or put those files in version control...
• nsxwolf 10y ago
  I worked for a company that grew considerably for 10 years and then lost its biggest client and folded quickly. We had spent a few years reworking our platform in a way that might have been successful enough to weather the storm of losing that client, but technical debt really slowed us down. Technical debt may not have killed the company directly, but we have to wonder how we might have done if we could have spent more of our time on new development.
  • greenail 10y ago
    This is revenue diversification not technical debt. Companies with a single customer funding the business should be actively pursuing a high priority strategy to reduce this risk.
    • nsxwolf 10y ago
      You misunderstand - our software itself was full of technical debt. We spent a lot of time dealing with the consequences of that debt, and I'm wondering if we'd have been able to hit vital targets sooner without it and possibly have survived.
    • paulddraper 10y ago
      It was both. The combination of two failures put them beyond the point of recovery.
• mywacaday 10y ago
  I've learned over time that its always better to assume that who came before me were smarter than me and knew more than me (I'm rarely proved wrong).
  • beat 10y ago
    "They did it that way because they where stupid" is a ridiculously common assumption, when the correct answer is often "They did it that way because they knew stuff I don't know".
    • lacampbell 10y ago
      There's obviously a lot of stuff I don't know then. Like the benefits of copy pasted code, or 300 column lines, or implementing the logic in 20 places when it has existed in the standard library for a decade. If only the ancient sage I inherited this code base from had left notes to guide me on this path of wisdom.
      • beat 10y ago
        See, taking a reasonable generalization and interpreting it as an absolute statement is a classic case of "assuming they're stupid".
        • lacampbell 10y ago
          I don't assume people are stupid. I assume they don't know or care how to write code well. Big difference ;)
      • corecoder 10y ago
        I've been there a few times, and the worst thing is when every five or ten WTFs there's something that seems as ill thought as the previous couple similar blocks, except this time it actually makes sense, as it implements (awkwardly of course) some important corner case.
      • khedoros1 10y ago
• krmboya 10y ago
  Would these be cases where Robert Martin's 'The Clean Architecture' [1] would help, where the core enterprise logic is separated from third party dependencies, making the latter easy to swap out and replace? I'd imagine a number of these cases are caused by a heavy reliance on third party technologies that are no longer supported, or very few people still understand. [1] https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-arc...
  • mason55 10y ago
    It's a great idea but in reality most third-party tools are going to work slightly differently and the abstractions will leak (unless they were developed against an existing interface, in which case you don't need to create the wrappers yourself anyway).
    • monk_e_boy 10y ago
      https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
    • kpil 10y ago
      I think the optimal route is to not bother with (extra) abstractions and interfaces, but try to avoid using things that is unreasonably tied to vendor - unless you save a lot of time. If the code base is not a pile of dung anyway, the cost of find/replacing and refactoring obsolete or replaced api:s once is so much smaller than the running costs of maintaining an extra layer of leaky abstractions for many years. It is guaranteed that the abstraction will not work without a lot of changes anyway, and what typically takes the most time is the regression testing.
• marcosdumay 10y ago
  > This does not happen with products that are highly successful business-wise, no matter how bad the suffering, so it's really a business failure rather than a technical one. One thing often feeds on the other. Because the system is hard to change, it does not get necessary features. Because it does not have necessary features, it provides less business value. Because it provides less business value, there is less of a budget for improving it. And so on.
  • beat 10y ago
    Bingo.
• contingencies 10y ago
  Yep. mysterious and unsolvable breakage: Helping another startup work through one now. It's a case of reclaiming functionality from a mystery outsourced codebase (without source control) meets inexperienced developers who try their hand at sysadmin plus a 100% rotated bevy of actors (the whole team, PM and all, have jumped ship), no documentation and no technical oversight. Offshore outsourcing adds cultural fun. unpleasantness: I would expand this to unpleasant or incomprehensible. I have seen projects be de-resourced because of lack of management comprehension when they literally paved the best and most rapid path to profit (later taken successfully by the now-dominant competition). antiquation: The best example of this I've seen was a hardware product an employer was developing as a joint venture in Taiwan early in my career. Engineers had made the decision to use a sucky chipset from a struggling company to save money, but the supplier went under and the API froze (bugs, missing functionality and all) before our product development could complete. The target feature set was literally impossible to implement on the hardware and nobody wanted ownership. Many millions of USD, wasted. replacement: It can work out, just infrequently. Generally when it works it's a smaller system with well defined interfaces.
• RantyDave 10y ago
  Heh. I have a rule of thumb: any project that starts with the words "this time we're doing it properly" is screwed.