Picking the proper names for software constructs is also part of that category. I'm always impressed at how choosing a slightly wrong-one can have a huge impact down the line. Somehow the brain doesn't map the name exactly to the current context and gets things wrongs, prevents clear thinking.<p>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".<p>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.<p>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 :)
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.<p>What this article describes is 'just' bad product design, the application works as designed but the end users are confused by the product.
The article, which I liked, is very end user-oriented, but I think that the ability of other programmers to interact with your conceptual models is just as important. Other people have to work with your code, and their ability to develop new features will very much depend on how easily they can work with your conceptual models. Onboarding programming hires into a poorly organized conceptual model will be a mess, and disheartening to the new person.<p>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.
>Technical debt happens when you make mistakes like choosing the wrong database or programming language for the task at hand<p>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.<p>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.<p>>The main issues in the case of technical debt are that the product is running slowly, not scaling well<p>Again, not really. The main issues are that the code gets buggier (owing to it being harder to reason about) and development gets slower.
I think this article is completely stupid, and is "conceptual debt" in not understanding fully what technical debt actually is. This article describes BAD PRODUCT MANAGEMENT.<p>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)<p>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.
We did a "team building" exercise once. The scenario was that our plane crashed 10 miles from a town in the Canadian winter. We had to prioritize 10 items from about 25 that we had on hand. Of course some groups decided to camp and wait for help, and others decided to set out on foot. People decided the usefulness of the items and made list. When it was all done, the answers were compared to those of a survival expert - who incidentally said we'd freeze if we tried to make the journey to town.<p>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.
I've often heard the idea that “the way the application is coded shouldn’t dictate its UI” which is true, but leads people to think that the application architecture should be divorced from the UI, and I don’t think that’s true either. You should first figure out the intended mental model of how the application works, and then from that should flow both the UI and the application architecture.<p>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.
I think the term he's struggling toward is something like "user experience debt" [1] or "product design debt" [2], an area that has been discussed for years.<p>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].)<p>I also find the "worse than technical debt" headline irritating. It's the sort of, "the thing I specialize in is <i>way</i> 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.<p>[1] <a href="https://medium.com/@vijayssundaram/user-experience-debt-c9bd265d521b#.ap1dujn8g" rel="nofollow">https://medium.com/@vijayssundaram/user-experience-debt-c9bd...</a><p>[2] <a href="http://andrewchen.co/product-design-debt-versus-technical-debt/" rel="nofollow">http://andrewchen.co/product-design-debt-versus-technical-de...</a><p>[3] <a href="http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215" rel="nofollow">http://www.amazon.com/Domain-Driven-Design-Tackling-Complexi...</a>
You have renamed "Design Debt," as outlined here back in 2004 by James Shore: <a href="http://www.jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Design%20Debt.html" rel="nofollow">http://www.jamesshore.com/Articles/Business/Software%20Profi...</a><p>Design Debt is not a new concept. It is a common cause of product failure. Taken from the link above:<p>"'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."
Honestly, all the conceptual debt I've encountered has been at the hands of bad product managers. Product managers who have no grasp on how users are using the system, don't talk to users, and just blindly create features for features-sake.
I've seen products marginally succeed with major conceptual and technical debt. But in the long-term, it's always bad news.<p>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.<p>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.<p>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.<p>I suppose it was the best thing that happened to me because it pushed me to work on my startup full-time.
The analogy with technical debt is poorly conceived. :) Technical debt (as with financial debt) should be a conscious trade-off; borrowing time now that will be paid back later. There's never any reason to choose a poorly modeled UI.
tl;dr: "Conceptual debt" is what Ward Cunningham described as "technical debt". That thing <i>you</i> call "technical debt" is just a combination of bad habits, haste and apathy.
This is why the API should ALWAYS at least have a first pass before any coding is done. Changing how things look and feel after the fact? Not an issue. Changing the underlying data structures? Holy shit, kill me now. Hell, if your API is solid (and you're using actual restful calls) then you should be able to completely decouple UI coding, business logic, and data management. Of course with the modern love of AGILE (see rapid prototyping) people wonder why so much rework is always needed because that's simply not the case.
An interesting side issue here is that bad conceptual model gets the more entrenched the more tests you add. Fixing the flaw becomes almost impossible because it breaks all the tests.<p>Testing is often presented as a panacea but this is one of the cases where it hurts more than helps.
I <i>want</i> to be convinced, but I'm not yet. TFA would be more persuasive if it included more than a single "software has two concepts that are effectively identical" example. I'm thinking of screwed-up shit I've seen in the past, and I don't know whether it fits into this or not.<p>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 <i>once</i> been communicated to accounting, and thereafter they <i>had</i> to see it everywhere, and it <i>had</i> 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 <i>much</i> more quickly.]
When I first read "conceptual debt" I thought it would mean poor architectural decisions as it relates to building software. Of course that's not what he meant. What he really means is what I would call "UX debt" if I were crafting a name for it.<p>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.<p>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" :)
This applies to much more than product design.<p>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.<p>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...<p>Avinash Kaushik wrote once, "spent 95% of the time defining the problem and 5% solving it."
> Conceptual debt is often the difference between a product succeeding or failing.<p>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 for bad design decisions."<p>"We're paying conceptual debt."<p>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.
I had a mild climactic sensation when I read the title of this post. I said the same exact thing a while back to my colleagues regarding some big conceptual errors that were made on a project a year ago and how I believe it will cost us a lot more than a years worth of work to pay this debt.