developer insights
Functional debt vs Technical debt: What’s the difference in a rich text editor?
Published {{setkaPost.lastUpdated}}
{{setkaPost.readTime}}
Technical debt is a well-known problem in software development. But in complex, user-facing software like rich text editors, technical debt isn’t the only problem. Functional debt is just as important, and it poses a threat to your product, the value it delivers and its usage growth.
![](\"millie.png\")
Millie Macdonald
Product Manager at Halo Connect
Rich text editors are full of complicated workflows and behaviours. There’s formatting options: lists, tables, images. Copy and paste. Media embedding. Spell checking. Links. Emojis… the list goes on.
Each of those features accrues its own technical debt, as does the underlying engine and other dependencies. This complexity makes managing tech debt in a rich text editor quite the job. It raises the risk of bugs, cruft, and code rot, decreased development velocity and even reduces user satisfaction as it creeps in from changes to the surrounding code or development ecosystem.
Generally, when you’re tracking and prioritising technical debt work, engineering mostly focuses on non-optimal code — or short-term implementation shortcuts — used to deliver a project faster.
But for many products, the code is only half the picture.
User satisfaction, value delivered and product marketability are as dependent on UI/UX as performance, and that’s where functional debt poses a threat. And similarly to technical debt, functional debt is hard to identify and pay down.
While most intentional and unintentional tech debt accumulates when coding shortcuts are taken, that often creates a new form of debt — functional debt.
But exactly what is functional debt and how do you manage it, especially in something as complex as a rich text editor (RTE) that’s dependent on a roadmap of continual feature releases?
What is functional debt?
Functional debt is caused by suboptimal or partially implemented functionality and UI/UX. While that feature may be coded well, its functionality is less than ideal — often lacking certain capabilities — so the value it delivers is impacted. This is functional debt.
UI vs UX: What are they?
UserTesting has a great article on the differences between UI and UX, including several different definitions by various UI and UX experts.
For example:
- A feature’s functionality is missing pieces due to time restraints or a misunderstanding of the user requirements.
- A user workflow is overcomplicated due to not enough time taken to streamline it.
- A feature was acceptable when it was implemented, but customer expectations have shifted and it now needs updating.
There are some broader definitions of technical debt that do include functional debt, but purely as a derivative of the overarching technical debt metaphor. However, Roman Predein’s article on technical and functional debt proposes a solid argument for separating functional debt from technical debt.
When they’re classified as separate entities, development and product teams have greater clarity and are better equipped to communicate the problems each causes, their side effects and recommending what to pay down when.
How is feature debt different from functional debt?
For more information on the differences, read:
The pros and cons of technical debt and feature debt
Costs of technical vs functional debt
To recap:
- Technical debt is about how a feature was implemented.
- Functional debt is about what was implemented.
The benefit of separating functional debt from technical debt, and understanding the ‘how vs what’ delineation, is that you can more clearly differentiate between the internal and external cost impacts on your rich text editor.
| Technical debt in a rich text editor | Functional debt in a rich text editor | |
|---|---|---|
| Example effects | - Developers regularly work around the limitations of the existing code - Customers report a bug that’s caused by badly architected code - Potential roadmap project requires that existing and incompatible code be refactored | - Users have to resize images by opening a dialog and typing in numbers, rather than dragging resize handles - Background and border colours can only be set on a whole table, instead of allowing granular cell-based styling |
| External costs | - Bugs - Performance issues - Browser changes and updates - Security risks | - Clunky workflows - Non-intuitive functionality - Outdated UI - Incomplete features |
| Internal costs | - Reduced developer velocity - Implementation barrier to roadmap features - Increased code complexity and fragility - Increased bug reports | - Decreased customer satisfaction - Increased feature requests from customers - Losing customers to more “modern” rich text editors |
Example costs and impacts of technical vs functional debt
Examples and causes of technical vs functional debt
Software debt appears at any point in the development cycle: planning, development, and maintenance can all cause debt. But certain types of debt are more likely to occur at different inflection points within the cycle.
These can be categorised into: choice, accidental, or outside forces and influences.
| Technical debt | Functional debt | |
|---|---|---|
| Intentional | Caused by choosing to take an implementation shortcut | Caused by choosing to take a functional shortcut |
| Unintentional | Caused by accidentally taking an implementation shortcut | Caused by accidentally taking a functional shortcut |
| Environmental | Implementation problems caused by outside forces | Functional problems caused by outside forces |
Causes of technical and functional debt, split by intentional, unintentional and environmental
Another way to view this conundrum is by the types of activities that cause the debt to occur. Rich text editors are inherently complex, with busy feature roadmaps, which creates an environment where both technical and functional debt rapidly accrue.
1. New WYSIWYG features introduce functional debt
It’s not unusual for intentional and/or unintentional functional debt to be introduced during the planning and development of new WYSIWYG features:
- Tight deadlines can cause functionality to intentionally be cut from a version of a feature. This creates debt that must be paid later for the feature to be fully functional.
- Lack of time or resources for user research or UI design can cause unintentional functional debt in the form of accidental limitations.
Intentional functional debt can and should be tracked, so it can be fixed later. However, unintentional functional debt is more likely discovered via customer feedback or support tickets.
Unfortunately though, not unlike technical debt, functional debt also quietly sneaks in over time.
2. Industry changes create environmental functional debt
How often have you opened a new app and thought, “Wow, this looks old”? Although when it was created, the app’s UI/UX probably met all the ‘modern’ standards. However, standards quickly change. And if you don’t keep up, that first impression of your product can be negative.
A gap opens between what was and current expectations, and that’s where environmental functional debt creeps in to fill the void.
UI Functional debt RTE example 1
Moving away from Microsoft Word
For a time, Microsoft Word was the most popular rich text editor. Its features, icons, and workflows were the gold standard for rich text editing.
Then, as new rich text editors appeared on the market, UI and UX ideas were borrowed from MS Word – mainly because that’s what developers and users were familiar with, which made the learning curve easier.
![](\"MS_Word_2007.png\")
![](\"Microsoft_Word_for_Mac_2011.png\")
User Interface (IU) for Microsoft Word 2007 and Microsoft Word 2011 for Mac.
Source
However in recent years, the rich text editing industry has exploded. There are now dozens of editors available, and they’ve all had to adapt to outside forces like the rise of mobile devices. Each mobile device sparks different UI/UX expectations and feature functionality, that users want to use on their phone.
This is the exact point where functional debt likely appears. And grows.
A feature built five years ago, based on MS Word, likely now looks and feels dated. Dialogs (once so prevalent), are now replaced with inline pop ups and other innovative UI elements. Shortcuts and gestures are expected, as are lists, tables, and media embedding.
But letting functional debt pile up in a rich text editor, is a shortcut to losing customers. And it’s exactly what prompted the creation of TinyMCE 5.0.
UI Functional debt RTE example 2
Paying back debt in TinyMCE 5.0
TinyMCE 4 worked well. Its UI was fairly clean, and the UI system was flexible for power users.
However, TinyMCE 4 was released in 2013 and soon after, React.js, Bootstrap, and Google’s Material design language became popular. Responsive web design and accessibility gained traction. There was also a surge in new libraries and frameworks, which caused rapid innovation in the web development industry.
In just four short years, the conventions that TinyMCE 4’s UI were based on, were outdated. It was starting to look tired and its architecture made it difficult to keep up with certain industry changes.
Functional debt was stacking up, purely due to environmental changes.
TinyMCE 4 still worked, and its UI could have been left as-is for a while longer. However, TinyMCE’s UI (and the framework behind it) is a core component of the editor, and paying down the debt required a replacement of the UI framework with a different in-house library, and rewriting the UI in the new framework. This was months of work.
It was decided that delaying this work was not a wise business choice. A total overhaul was commenced.
In February 2019, TinyMCE 5.0 was released with:
- Completely overhauled UI
- New icons
- New dialogs
- New buttons, and
- New UI framework.
The entire UI engine was replaced, and every UI component rewritten from scratch. However, due to the size of the project, it only addressed UI-related functional debt. The underlying core engine had been completely untouched – including all the known and hidden technical debt it had collected.
Balancing technical and functional debt in TinyMCE
Engineers tend to notice technical debt. Designers more likely notice functional debt.
That’s perhaps an over simplification, but it’s an example of how different people (and roles) can be biased towards noticing a type of – due to their knowledge and expertise. But having and paying down ‘just the right amount’ of tech debt is important to a good product. How do you balance it?
Here’s three of the many phases we worked through with the TinyMCE core engine, when identifying, prioritising, tracking and paying down our technical debt.
1. Identifying and fixing technical debt in rich text editors
Engineers are great at identifying technical debt, because it tends to make their job harder.
Rich text editor specialists would agree – in fact, they’d likely say an editor tends to breed technical debt. Ask any of our developers about their least favourite piece of code to work on, or the weird workarounds they’ve had to use every day and a list of technical debt to tackle, quickly takes shape.
Another great source for insights on possible tech debt, is your support team’s list of bug reports, or you can use the many code analysis tools that are available.
However, when it comes to paying down the technical debt that's accrued, the list of ‘doers’ is much shorter. Fixing it generally falls within the realm of the engineering team, either by planning the work within regular sprints or as major overhauls.
2. Identifying and fixing functional debt in rich text editors
By comparison, functional debt can be difficult to find. And fixing it often requires a wider team of people.
Because functional debt is user-facing, fixing it often requires a higher proportion of external research and testing than what’s usually used for code-based technical debt. User testing, UI/UX design, A/B testing, and user flow analysis are likely required to find the right fix for functional debt. And that’s before your engineers start testing for technical validation and implementation.
Insights on the complexities of RTEs and technical debt
Reduce technical debt with the right rich text editor
Is your code half-life shorter than your engineering career?
Managing technical debt is difficult in rich text editors
Dangerous examples of technical debt in rich text editors
Are developer velocity and technical debt impacted by a rich text editor?
The other challenge is noticing functional debt in a rich text editor.
Functional debt that’s been intentionally taken on during the development of a feature, can and should be tracked. But the real (hidden) danger comes from unintentional and environmental functional debt.
The danger here is that users become too used to the way things work to realise there’s functional shortfalls. This is particularly true for the people within your organisation – constantly working on a product makes its quirks seem normal and blinds you to its problems.
Of course, there’s some functional debt that’s so glaring anyone can see it – but a lot of it is much more subtle. To find your functional debt, you often need one of two things: fresh eyes, or broader experience. So employ:
- User testing (especially with new users) should focus on expectations, pain points, and inefficiencies. This can be an invaluable method to identify functional debt.
- Feedback from new hires (as they learn the product) can help to identify both technical and functional debt that older hires are no longer paying attention to.
- In-depth competitor research and comparisons can highlight oddities that customers may stumble on.
GOT TECH DEBT ISSUES?
Before you discuss tech debt with your management or dev team, learn why managing technical debt is difficult for rich text editors.
3. Pay down technical or functional debt in rich text editors
Now you have a list of your technical and functional debt, which do you pay down first? Here’s some questions to help filter your decision-making process:
- Is your development velocity as expected, or are you being dragged down by your tech debt backlog?
- Are any of your planned roadmap items likely to be blocked by existing tech debt?
- Do any of your editor features get constant bug reports from customers?
- How often are users looking for information about how to do something with your editor, whether via Google, support channels, or your docs?
- What do users say about your UI/UX in user testing?
- How often do users ask about changing the styling of your editor, or extending its UI?
- How big is your feature request backlog?
Hints:
If more of your problems align with the first three questions, you should probably address your tech debt backlog.
However, if the last four questions are of more concern, then functional debt may be your bigger problem.
Technical debt example: TinyMCE 6.0 core engine
As mentioned, the breaking changes in TinyMCE 5.0 mainly focused on UI and overcoming its functional debt, so the other (non functional) tech debt that had been accruing in the editor’s core engine since TinyMCE 4, was still untouched.
Multiple pieces of debt were affecting developer velocity, stability and security, and the costs of leaving them unaddressed were growing. The planned 2022 release of version 6.0 of TinyMCE, was a convenient time to tackle the accumulated technical debt in the core engine.
a. DOM Parser
The single biggest piece of technical debt in the editor’s engine was the DOM Parser.
The task of maintaining a DOM Parser was once a key part of developing a secure rich text editor. However, it’s a complicated and finicky piece of software, especially in JavaScript. And it requires constant updates to keep up with the latest security vulnerabilities, browser changes, and best practices.
Thankfully, by TinyMCE 6.0, there were industry standard tools and APIs that could be utilised instead of maintaining an in-house DOM Parser.
b. General technical debt
Other changes were made to TinyMCE’s architecture, to enable potential roadmap projects.
A lot of cruft and baggage was removed, such as the code that supported IE11, which reduced development overhead and the surface area for potential bugs and vulnerabilities. And, thanks to TinyMCE 5.0’s major UI overhaul, the reskinning of TinyMCE 6.0 took significantly less effort than it would have in the past.
On reflection, focusing the paying down of our functional debt (UI related) and technical debt (core engine) in separate major releases (ie. our 5.0 and 6.0 overhauls), made the task of project scoping and management much easier. It allowed our team of expert rich text editor developers to focus their attention and more clearly communicate the effects on our customers.
That said, ignoring one type of debt, for too long, isn’t wise. Instead, you need to balance the ongoing challenge of what and when to address software debt.
BUILDING A RICH TEXT EDITOR IS HARD
Before you suggest building your own WYSIWYG editor, to either management or your dev team, learn the real price tag of building a rich text editor.
Rich text editors continually accrue technical and functional debt
The rapid pace of changes in the web development ecosystem and rate of rich text editing innovation, generates major threats – in the form of environmental functional debt – to every rich text editor. And it looms over inhouse builds, as well as every open source and commercial editor.
It's a given that every editor must upgrade and add new features to satisfy changing standards and user expectations.
That effort takes significant expertise and time, as well as deep domain knowledge to know whether to pay down software debt vs implement new features vs solve support tickets. It’s a never ending conundrum.
The biggest question to ask yourself is: do you have the resources to do it? Or would it be easier to buy a full-featured, enterprise grade editor from a third-party specialist?
Download the white paper
Opportunity Cost of Technical Debt: Minimize Your Rich Text Editor Development
![](\"1548508487603.jpeg\")
author
Millie Macdonald
Product Manager at Halo Connect
Millie is a Product Manager at Halo Connect who dabbles in writing. Previously, she worked at Tiny as a Product Owner, dev, and QA engineer. She loves learning above all else, whether it's about people, tech, or leadership.