Hacker News Reader

Comment by apalmer | Hacker News Reader

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 software may work as designed to the user there may be unseen technical trade offs that have a real measurable negative impact in the long run.

What this article describes is 'just' bad product design, the application works as designed but the end users are confused by the product.

View on HN

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.

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?

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).

Exactly. The important part of these phrases aren't Technical or Conceptual, it's the 'Debt' part.

Let's just call it bad product or bad UI. That way we don't need lengthy articles to explain new terms.

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.

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".

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.

You're describing an effect, but this article is looking to understand the causes.

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.

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?

I'd consider it Design Debt or UX Debt -- When you justify the continuation of bad decisions in order to keep consistency.

Reply on news.ycombinator.com