4 ms·

I think the term 'Conceptual Debt' is not helpful. The reason why 'Technical Debt' was coined was to help non technical shareholders understand that although so

• jey 11y ago
  You're describing an effect, but this article is looking to understand the causes.
• jonahx 11y ago
  The distinction is not only helpful, but fundamental. You can have clean, beautiful code that implements poorly-named, ambiguous, or half-baked concepts -- that's conceptual debt. You can also have a well thought out product, broken down into simple concepts, that is implemented by inexperienced programmers as a mess of speghetti code -- that's technical debt. Granted, the two often go hand in hand, but not always, and even when you have both, it's helpful to separate the two, as they require different remedies.
  • gotchange 11y ago
    Isn't the concept of "Conceptual Debt" antithetical to the idea of MVPs,lean startups and the "ship fast, ship often" mantra dominating the tech culture nowadays?
    • alistairSH 11y ago
      No. Start-ups (and anybody else for that matter) just make certain compromises in order to ship fast(er). They still create conceptual debt, just as they do technical debt. The key is to go back and address both before they become uncorrectable (or, at least document/understand those compromises, so future developers don't waste time figuring it out).
      • jskulski 11y ago
        Exactly. The important part of these phrases aren't Technical or Conceptual, it's the 'Debt' part.
  • rejschaap 11y ago
    Let's just call it bad product or bad UI. That way we don't need lengthy articles to explain new terms.
• dclowd9901 11y ago
  There's also a problem around incorporating this notion with the notion of agile product development. After all, how are you supposed to conceptualize a product around user expectation if you don't know how users are going to, well, use it?
• nicoslepicos 11y ago
  Bad product design = conceptual debt. It's a nice way to be able to say the costs you incur from making bad design choices early on, that now need to be dealt with and can be fixed. But the concepts are not only in the product design, but also reflected in the software system architecture, since that will reflect the design. One weird thing that happens is that developers insist that there is some sort of technical constraint, and then the product design reflects the software system architecture, rather than the software system architecture reflecting a product design well suited to users' mental models.
  • collyw 11y ago
    The debt part implies that it can be paid down, which can be applied to technical debt. Concepts will tend to stick (they are often at the very core of the application), so I am more inclined to agree that "bad design" is more appropriate than "conceptual debt".
  • cerrelio 11y ago
    I'm dealing with this at work in an odd way. The users of the product are machines, as it is a predictive inference system. Humans will never directly interact with the product. So if you think about it, the input data is the user in my group's case. Due to the failure in recognizing this twist the decision was made to have a very restricted way of representing features (metadata). The concepts in code base are all linked by the restrictions. There have been a few painful refactorings in the past year, and I don't see an end to it unless those restrictions are removed. So this phrase extends well to systems without human users. Although like others I do agree that "bad product design" is probably a better term, but "conceptual debt" sounds more sophisticated.
• wvenable 11y ago
  I was included this "conceptual debt" in the concept of "technical debt" when I think of it -- It didn't occur to be compose it down further and so I agree; I'm not sure it's helpful to do so.
• omgbear 11y ago
  I'd consider it Design Debt or UX Debt -- When you justify the continuation of bad decisions in order to keep consistency.