A good example is the RAILS_ENV environment variable. It's a mechanism to select a running mode of rails applications. Now unlike most applications debug mode is the default. It's called "development" and the normal mode is called "production".
Because of these naming decisions developers always confuse the RAILS_ENV to be related to the deployment target. They add a "staging" running mode and they start bundling configuration secrets into the code. And invariably these secrets get leaked on github when they decide to make the repo public.
For a long time I felt something wasn't right and couldn't point the finger at it and it took conscious effort to disambiguate that. And that's just for a single variable. Mind your naming :)
Similarly I'm often shocked at just how critical name disambiguation is. There's a shocking number of extremely similar concepts when writing code which, when given the same name ends up causing bugs.
A good example is 'file' which can be used to refer to a file handle, file name, file object of some other kind, a 'file' representing an aggregate of information on person, and often it ends up referring to directories, devices and links as well.
Now day in and day out, I have to deal with classes like ItemViewer, ItemListController, etc etc, and half the time I have no idea what the responsibility, location or relationship of any given class is supposed to be. So much time just getting contextual background before I start working in an area of code. Couple this with early bad coding decisions around encapsulating responsibility and lack of testing coverage and I've got a relatively miserable 2-3 years ahead of me.
I prefer to call my stuff "things."
As you've observed, it's not really possible to go back and fix this kind of mistake after it's been made.
Personally I find it an improvement to have two terms that separate the concepts, if for no other reason that it underscores that 'conceptual debt' is a thing that matters a lot and isn't just 'the engineers can come in and clean it up later' type of deal, which technical debt often can be. Recognizing conceptual debt as something that all team members can contribute to, not just people writing code, is a profoundly different type of conversation than the ones you'll have today around tech debt where it's assumed a) stakeholders can't understand it and b) it's nobody's problem but the engineers: they create it, they pay it down.
I will certainly use the phrase.
When a major customer needs a new feature, do you hack that feature into the codebase to save the account? Or do you risk the account in order to add the feature The Right Way?
I think that we arrived here specifically because we don't have a term for the effect of careless code change. 'Technical Debt' ended up being appropriated as a term for it.
As much as it hurts my engineering sensibilities, 9 times out of 10, being hasty is better than not existing.
I've been adopting this rule of thumb that the first pass at a new product I can just dive in and treat it as a throwaway, since I probably don't understand the domain well enough to develop an ideal conceptual model anyways. The key here being to treat it as a throwaway and then return and do a rewrite from scratch once I have a better understanding of the problem.
Speed and Quality need to be in balance.
What this article describes is 'just' bad product design, the application works as designed but the end users are confused by the product.
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.
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.
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.
In my experience, apps that start code-first tend to end up a CRUD apps and require a lot of composition from the end-user; apps that start UI-first tend to generate a lot of exceptional use cases and workarounds. Both give the user a muddy mental model of how the application should work.
Good conceptual models can be extended, interacted with, and built upon, and that which an end user may regard as a "feature," including features not yet thought of, flow naturally from the best models. So there are some knock-on benefits to the end user from good conceptual models under the hood, even if the end user doesn't see them or have an opinion about how intuitive they are.
It's unclear to me how those two things are related. They _can_ be related, but it doesn't seem like they have to be. Not sure.
The cost inflicted on the coders is not coders' conceptual debt, but users's conceptual debt - certainly costly to coders as they have to support multiple patterns, but I think there is a difference. I guess when I think of coders' conceptual debt, I'd think of something that may be abstracted away at the UX level such that the user doesn't see it, but inflicts pain on implementors due to counter-intuitive patterns.
Technical debt mostly means duplicated code, tightly coupled code and code that isn't programmed to fail fast. Those things can be impacted by the wrong choice of programming language or database but only indirectly.
Most of these things are pretty much unavoidable the first time you write code and you can only fix them once your code is surrounded with tests.
>The main issues in the case of technical debt are that the product is running slowly, not scaling well
Again, not really. The main issues are that the code gets buggier (owing to it being harder to reason about) and development gets slower.
You took the easy path early on because it let you focus on acquiring customers and then you had to improve it later.
Also, if Twitter and Facebook started out building their product to be used by millions of users, they would have gotten nowhere. They would have 0 users right now.
You can't really say Facebook took the easy path either. They went as far as creating a virtual machine and dialect based on PHP. And who knows what they had to do to get MySQL to scale like that.
I think "conceptual debt" is a poor choice of phrase here, as one important kind of technical debt is the sort of software design debt where your domain model ends up being a poor fit for your domain, often because the domain concepts themselves shift. (For those interested, "Domain-Driven Design" is a great book relating to this [3].)
I also find the "worse than technical debt" headline irritating. It's the sort of, "the thing I specialize in is way more important than the thing you specialize in" thinking that is poisonous in a team environment. Which one is actually worse depends a lot on your product and your business conditions.
[1] https://medium.com/@vijayssundaram/user-experience-debt-c9bd...
[2] http://andrewchen.co/product-design-debt-versus-technical-de...
[3] http://www.amazon.com/Domain-Driven-Design-Tackling-Complexi...
Conceptual debt is product design debt like you're suggesting. In particular, I think of it as a subset of product design debt that has to do with domain modeling as you suggest vs. having the write domain models but having poor user flows around those core concepts.
Unlike user flows, concepts are also reflected in the API & Object Models in your codebase so those may be trickier to change than the user flows that revolve around them.
Design Debt is not a new concept. It is a common cause of product failure. Taken from the link above:
"'Design debt' explains the problem. When a team is working under pressure, they take shortcuts that compromise design quality. It's like taking out a high-interest loan. The team gets a short-term boost in speed, but from that point forward, changes are more expensive: they're paying interest on the loan. The only way to stop paying interest is to pay back the loan's principle and fix the design shortcuts."
To me at least, what OP described as "conceptual debt" is really just design debt. Which all seemed like down to earth technical debt. I honestly see no reason to distinguish the three. Plus they typically stem from the same sources - that is, enterpreneurs and managers that want an MVP without actually grokking the V bit in the latter acronym, and managers who cut corners to slash short-term costs.
By contrast, technical debt is very different from, say, organizational debt. Which arises when your organization's staff grows faster than it's able to organize the workload around new hires.
Bad conceptual design is due to poor communication between end-users,product owners, and coders.
The reason a product owner can't handle all conceptual issues in advance is because he speaks english, and not logic. His terms are poorly defined compared to the need of a mathematicaly correct definition of his problem space. Only when you start to code things do you realize that things are much more complicated ( or can be simplified).
I know what you mean about changing underlying data structures too. There are ways to fix the issues after the fact. E.g. wrapping existing concepts in other ones, and then gracefully deprecating the old ones. But, it definitely creates all sort of weird tensions with customers that are using the old concepts.
Testing is often presented as a panacea but this is one of the cases where it hurts more than helps.
If you need to write quality code, you will need to invest in writing tests. If you wrote the wrong code, yes, you will need to rewrite the tests. But that's a different problem.
See Mythical Man-Month (https://en.wikipedia.org/wiki/The_Mythical_Man-Month)
I don't think it's helpful to create a new term to describe something that could be easily encapsulated by using a term that most everyone already knows, is industry standard, and is implicitly obvious to anyone versed in the practice of building software products. Right now "bad UX" would be the same as "UX debt". That terms makes sense to me because it codifies a real concept that I've absolutely held in my mind.
With all due respect to the author, and I applaud his effort to try to improve communication tools, I believe this name has "conceptual debt" :)
DEBT is an instrument. A good CTO/Developer will know when the codebase/product/platform is taking on technical debt. The same way you might take debt for a house, and pay back over time so you can LIVE in it. Shitty CTO's/Developers will take on tech debt without knowing it, and soon enough you're fucked. That's how people become homeless in the real world with real debt. (Well one way)
There is NEVER a time when you want to take on 'conceptual debt' AKA make crap product choices. That is just being stupid or short sighted. The only time to take on conceptual debt is if I am a development agency being paid by rich stupid people, and I want to make as much money as possible and not care about my reputation with them.
I made the point that the "correct" list of items was strongly dependent on which top level strategy was chosen, and that this was a reason for solid planning from the top. If your product is holding off on big decisions because the leaders can't make them, you'll be working toward multiple possible outcomes at the same time and burning a lot of extra effort.
It's more difficult to compete because you can't easily move forward without breaking a bunch of already existing features and it ends up costing the company lots of money because of the extra time needed to complete anything.
I think the worst case I never saw was an app that was built by overseas developers. The boss, who knew nothing about technology or software, just wanted something cheap and fast. When I came on board as a consultant, we had two parallel apps (the new one and the old one) and any new feature took 10X as long.
Customers slowly left to competing apps that could move much faster and the boss ended up letting all of the US-based developers go. She told me in my exit interview that she could hire 3 people in India for what she was paying me.
I suppose it was the best thing that happened to me because it pushed me to work on my startup full-time.
For instance, one company that employed me spent extra person-years creating new service plans because a single internal index in a vendor-supplied product had once been communicated to accounting, and thereafter they had to see it everywhere, and it had to take different values everywhere. Actually I think the accounting department would have had to lay someone off for inactivity if they couldn't spend so much time tracking this one stupid DB key through nineteen different reports. Was that "conceptual debt"? [EDIT: to be clear, "creating new service plans" was a good thing, that allowed us to acquire more customers. If the interface to G/L hadn't been fucked up in this fashion, we could have done that good thing much more quickly.]
I see many Adwords accounts that are structured based on a best practices boiler plate format...but fail to consider how the structure will interact with decision making in the future, forcing poor budget allocation or worse, making proper optimization unfeasible.
Having a very clear vision from the outset for how you will need to adjust and optimize in the future and building an account structure in format that aligns with those processes is often the difference between a very successful account and a mediocre account that only shows minor incremental growth...
Avinash Kaushik wrote once, "spent 95% of the time defining the problem and 5% solving it."
Is it, though? I have seen plenty of products that succeed with plenty of the type of debt the article speaks of.
"We're paying conceptual debt."
Which phrase sounds more clear to you? Also, which phrase exists for the sole reason of communicating nothing while making you sound more intelligent? I truly hope "conceptual debt" doesn't become a new buzz word.
