Developer insights
Reduce technical debt with the right rich text editor
Published October 25th, 2022
Technical debt only affects legacy tech, right? Think again. Unless your stack’s been magically untouched by digital transformation, or you’re working in an other-worldly place where code is always pristine and developers never have to make trade-offs, then that idea isn’t true. Every development team has tech debt.
Di Mace
Marketing Communications Manager at Tiny
TABLE OF CONTENTS
Brantly Smith* found that out the hard way. Having landed the role of CIO at Zorg Tech* in the crazy aftermath of Series C funding, he didn’t do a tech stack audit. His usual practice was to account for every piece of infrastructure and application, to get the lay of the land. But things were moving so fast, it kept slipping down the priority list.
Plus, he’d thought the rule of thumb for scaling start-ups was in play – that none of the code is written to last long – so its short life meant it was in pretty good shape. How wrong he was.
Grumbles were being heard from the engineers, “Every time we go into an area of code, we’re working around poor designs”. He knew that was a warning – the code needed some attention. He’d gambled that the stack wasn’t carrying technical debt, and on the whole he was right, but one particular component was causing grief.
The rich text editor they’d hurriedly built for launch couldn’t scale as fast as they needed, and probably needed rewriting from scratch.
Start-up rule of thumb: none of the code is written to last long
Coding new functionality in their rich text editor (RTE) to handle the application’s growth, plus the upgrades and features it needed to stop breakages, was an endless cycle of work. Zorg Tech* developers didn’t have the experience to know when and why to take on tech debt for the editor and at what point to start paying it off – to avoid slowing down their product development and feature improvements.
Ideally they needed to reduce technical debt on their editor, by finding ways to minimize its accumulation. Because the editor was affecting their app’s growth.
*Company and personal details are fictional, but indicative of the issues related to building and maintaining a functioning rich text editor and advanced features.
The complexities of technical debt in rich text editors
Maintaining a RTE was far more complex than the Zorg Tech* dev team had believed it would be and that naivety was proving costly – in time, money and developer talent.
By building their own RTE, they’d taken on complex, costly code work that was outside the SaaS company’s core focus, and it had produced shortcuts, low-quality, temporary-but-not-really workarounds and other hackey short-term solutions… to get through the launch window.
None of it was viable for the app, in the long-term.
Now, no one wanted to work on code that was full of the cruft left from those rushed decisions, temporary fixes, short timelines and lack of domain expertise.
Plus, it wasn’t just the main editor’s initial coding and subsequent refactoring that needed to be fixed. Each individual plugin (feature), every linked service, library and tool, as well as continual browser changes were all generating technical debt and work that the team hadn’t accounted for in their total cost of ownership (ToC) and maintenance budgets.
It seemed to Brantly Smith* that everything about the rich text editor needed to be monitored, reworked and maintained. All the time. But it was a catch-22.
The more time his dev team spent on refactoring the deficiencies, it slowed their product innovation, and lowered morale. But without the refactoring work, the growing tech debt was affecting the app’s overall code quality and ultimately end users were beginning to get affected. While the app was functioning and users were satisfied, it could never reach its full potential until the RTE deficiencies were fixed.
Maintaining a RTE was far more complex than the Zorg Tech* dev team had believed
Dodge unnecessary development and reduce technical debt
Five years in, the start-up had realized a crucial error. The decision they had failed to make at the outset, was to buy a specialist rich text component from a domain expert, that was built for scalability. If they’d done that, their ‘owned’ tech debt would be reduced and someone else (the domain specialist) would be carrying the tech debt load.
Instead, their in-house-built RTE had unnecessarily generated a massive technical debt. And it wasn’t going away anytime soon.
Once Brantly* was aware of the problem, he researched the available options and found a solution to seamlessly integrate with their app – that even included the advanced plugin features that they desperately needed. They effectively reduced (if not almost eliminated) their technical debt, by buying-and-assembling the right RTE component.
And they could realize the opportunity cost, from on-time launches, much quicker.
...realize the opportunity cost, from on-time launches, much quicker.
What is technical debt
Technical debt is an analogous metaphor that’s used in software development, and draws parallels between incurring financial debt and some form of development debt, which eventually needs to be paid off.
Similar to financial debt, in technical debt, the principal part of your debt is the time saved during your initial implementation (through shortcuts, deficient code quality or other temporary fixes implemented) while the interest is the additional time, quality, and risk costs incurred until the debt is resolved.
A crucial part of managing technical debt is a solid payment plan and formula that uses it wisely to fuel your growth when it’s most needed. The hidden danger, however, lies not in the debt itself, but in allowing it to accumulate with no plan for paying it off.
Some companies find that actively managing their tech debt frees up engineers to spend up to 50 percent more of their time on work that supports business goals. The CIO of a leading cloud provider told us, ‘By reinventing our debt management, we went from 75% of engineer time paying the [tech debt] ‘tax’ to 25%. It allowed us to be who we are today.
Who Invented the Term Technical Debt?
Ward Cunningham, the developer of the first wiki and co-author of the Agile Manifesto, first explained and aligned technical debt, using the metaphor of financial debt.
The principal part of your technical debt is the time saved during initial implementation, while the interest is the additional time, quality, and risk costs incurred until it’s resolved.
Where does technical debt come from?
Technical debt occurs where short-cuts are taken in writing code or when suboptimal design decisions are made. Those less-than-ideal decisions are often driven by:
- The need to release quicker
- Developer inexperience
- Need to overcome code architecture shortcomings
- Temporary workarounds that it’s known are being addressed and updated in the future.
Another term that’s frequently used in relation to technical debt is ‘cruft’. As an accepted shorthand for many things, cruft is (generally speaking) some form of technical debt that eventually needs to be paid. Martin Fowler defines cruft as “Software systems are prone to the build up of cruft – deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further.”
Cruft also includes “...“things” that were left temporarily in the system during the previous iteration. Also, cruft refers to any code that is not necessary to perform the task it was designed for or forgotten code without any utility. Although cruft does not mean a code bug, it makes the code harder to maintain or to read and creates technical debt.”
Complex development work, like rich text editors, that fall outside your strategic focus often produces technical debt. And your developers end up hating those parts of the code base. That’s the exact problem Brantly Smith* and Zorg Tech* were battling.
Much of a rich text editor’s technical debt is driven by the complexity of the code, its dependencies, libraries and browser updates. Tracking it and even more importantly, identifying areas that likely have ‘potential’ tech debt, is very difficult.
However, specialist dev teams that work on large complex projects year-round like rich text editors – with anywhere from 484,093 to 270,122 lines of code (LOC) in just the core editor – have the domain knowledge to know when to make the right trade-offs and decisions, to capitalize on an opportunity cost. So you can meet your launch deadlines and revenue growth projections.
What are the consequences of a technical debt?
Carrying too much technical debt slows your dev team’s agility. It sucks energy away from your software innovation, and slows growth. Opportunities are lost. Conversely, by having too little debt your ability to scale fast, ship fast, and test in-market can be stifled. Value to your users slows.
A Microsoft study in 2017 concluded that 58% of a developer’s time is spent on code comprehension, especially once the software is shipped and has to be maintained. It’s something most developers intuitively know: “...the less you’re familiar with the code, the longer it takes. The more surprises are in your way, the longer it takes. The harder it is to reproduce all scenarios, the longer it takes to get it right.”
And we all know that hard to read code, eventually equals technical debt.
Ideally, you want to have a ‘Goldilocks level of tech debt’ – not too much, not too little. So your tech debt management plan must ensure the negative consequences of tech debt don’t exceed its advantages. By balancing growth and housekeeping, you can reduce your technical debt and continue delivering value at high speed, without sacrificing quality.
How do you calculate the cost of technical debt in rich text editors?
Each organization has different variables in play, but in an attempt to better quantify the cost of technical debt in RTEs, let's take some conservative numbers and do a little math.
For illustrative purposes, using the most verifiable data, here’s a basic calculation of the cost of technical debt for an organization that specializes in rich text editors, with a team of 50 developers dedicated to its maintenance and extensibility work.
1. Average time spent on tech debt
According to Stripe’s Developer Coefficient report, over a 40-hour work week, developers spend 17.3 hours or 42% of every week dealing with technical debt (13.5 hrs) and bad code (3.8 hrs), which equates to nearly $85 billion worldwide in opportunity cost lost annually.
Source (page 5)
2. Average cost of technical debt per developer
The average base salary for a Senior Software Engineer in Silicon Valley, CA, is US$146,985* per year excluding oncosts, RSUs and bonuses. (*As at 20 Sept 2022)
Note: Each country and region have differing salary rates, taxes and on-costs, therefore the cost in your country may not correspond with the below example calculation.
3. Size of development team for the rich text editor and advanced features
For illustrative purposes, the development team working solely on the core rich text editor, its range of core and premium plugins features, technical debt pay downs, maintenance and extension work, comprises 50 developers, 5 days per week, working 40-hour days.
4. Cost of technical debt calculation
Number of developers on dev team
50
Average salary cost per developer
US$146,985
Total cost of developers per year
US$7,349,25
Cost of tech debt per developer, per year = average cost per developer x percentage of time spent on tech debt work
US$146,985 x 42% p/week on technical debt
US$61,733.70
TOTAL cost of tech debt = average cost per developer x percentage of time spent on tech debt work x number of developers
US$146,985 x 42% p/week x 50 developers
US$3,086,685
That amounts to approximately US$3M in technical debt work, undertaken every year, on a rich text editor and its plugins.
As Zorg Tech* quickly found out, unless you’re a rich text editor specialist who knows when, why and how to safely take on and manage the technical debt that these complex projects generate, that's a lot to take on. But what’s the alternative?
Smart organizations are sidestepping the RTE tech debt hole.
They’re creating tech debt management plans that include the scoping, sourcing and maintenance of reusable components with built-in scalability. That approach reduces their ‘owned’ tech debt – instead of building it themselves, they're buying, assembling and integrating those complex components.
US$3 million p.a. spent on technical debt work for a rich text editor and plugins
Reduce technical debt with the right rich text editor
Yes, all code has technical debt. That’s normal.
And yes, rich text editors generate a large amount of tech debt. All the time.
But according to Gartner, infrastructure and operations leaders who can actively manage and reduce technical debt achieve 50% faster delivery times. By intentionally taking on and wisely managing your technical debt, it can fuel growth, allow innovation to occur rapidly, and market deadlines are met.
If you’re like Zorg Tech* and suffer from an inability to scale, productivity hours are being squandered, opportunities lost, and you’re failing to deliver on user expectations or value… it could be the result of the not-so-obvious tech debt issues that come with trying to make a poorly-chosen (or built) WYSIWYG editor work in your tech stack.
Don’t keep that ugly duckling component in your tech stack. It’s never going to be a swan, without help.
Download the white paper
Opportunity Cost of Technical Debt: Minimize Your Rich Text Editor Development
author
Di Mace
Marketing Communications Manager
Messaging strategist and copywriter whose passion lies in working with brands like Tiny, that have deep-seated values and embrace the power of their story. She gets a kick out of solving problems, loves learning new things and making stuff, every day. When she’s not thinking through clever copy lines or clarifying value propositions, she’s knitting amazing socks for everyone she knows.
Related Articles
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.