TinyMCE
MoxieManager
Drivedeveloper insights
Are developer velocity and technical debt impacted by a rich text editor?
Published January 17th, 2023
16 min read
Technical debt is unfinished business. It represents all the things you didn’t want to, or couldn’t do. For rich text editor developers, not quite done user stories are common – in every sprint. But those small debts add up, and they impact your team’s capacity. Why’s that? Because tech debt is the arch nemesis of developer velocity.
Di Mace
Marketing Communications Manager
As a headless platform, the Attract CMS* plays a vital role in determining which omnichannel opportunities its users can and can’t pursue. New features are frequently released, at a frenetic pace. Agile development practices facilitate that speed, but it also means corners are frequently cut – bad design, incomplete testing, bugs, refactoring ignored and unknown requirements emerging – resulting in stories being not quite done at the end of each sprint.
Lead engineers, Kai Solongo* and Lani Hart*, are accruing lots of small technical debts, that add up to something big. Reduced developer velocity.
The constant weight of those small debts is being dragged around by the Attract* dev team. Every day. And because of that debt, backlog tickets aren’t always completed in a sprint, so the Definition of Done (DoD) and Acceptance Criteria (AC) for projects aren't being met. So what’s causing it… a specific component, or the entire code base?
For the Attract CMS* dev team, the lengthy list of refactoring, browser updates, old code and iterations on their rich text editor (RTE) – a key component of their CMS platform – means work on the editor is never truly done. It’s so bad, the Scrum teams now avoid the editor and regret they ever built it themselves.
Something needs to be done.
What is the Definition of Done’ (DoD) in Scrum?
According to Scrum Inc. “The Definition of Done (DoD) represents the organization's formal definition of quality for all Product Backlog Items (PBIs). If an organization does not have one, the Scrum team should set its own.
By knowing when a product or project is ‘Done’, it helps Scrum teams to avoid loops of iterations that complicate a project, more than improve it.
Let’s look at an ‘average’ sprint at Attract CMS* to see how the technical debt on its RTE is dragging down developer velocity.
*Company and personal details are fictional, but indicative of the issues related to building and maintaining a functioning rich text editor and advanced features.
A rich text editor’s troublesome technical debt
The Attract CMS* dev team is frantically working to meet a release deadline, and it’s the last sprint before launch. Things appear to be on track, but the schedule is tight. At stand up, Jarrod* describes an upgrade he’s working on within the rich text editor – improved tables formatting – and how it’s much more complex than what was expected.
He estimates it’ll take 18 hours to properly complete it, but there’s not enough time left in the sprint. Scrum Team Lead, Lani*, suggests an 8-hour alternative that cuts corners, but allows the team to meet the most critical things needed for release. After debating the pros and cons, the team decides to do the workaround and create a backlog item to clean up the feature, after the release.
Finally, the feature’s completed, launch date achieved and 10 hours of productivity are gained (on the principal part of the debt) – by taking on that seemingly small technical debt – and everything keeps moving forward. (Except of course, that the feature wasn’t actually done during the sprint, based on the Scrum team’s DoD and AC).
After the release, the feature is demoed to a big-name prospect, who uncovers some bugs during their technical review. The race is on for the dev team to fix the bugs and secure the client. Needless to say, the technical debt backlog ticket (for the workaround) never makes it to the next sprint. Or the next, or the one after.
Several sprints later, Kai* discovers that because the tech debt is still unpaid, he needs to spend several extra hours of development while implementing another related, new feature in the rich text editor. The extra time requirement represents the interest they’re paying on that initial, small debt they took on, and it continues to balloon with every additional dependency that’s slowed by the unpaid debt. That one small debt keeps creeping into other dependencies and spreads throughout related sections of the editor’s code base.
Their progress spirals down. Until the weight of tech debt from the rich text editor is cut free, the team continues to drag it around and their overall efficiency is affected.
Slowly but surely, senior management notices the team’s developer velocity metric is dropping. Given management’s obsession with velocity, that’s bad news for Kai*, Lani* and the whole Attract CMS* engineering team.
***
While not endemic to every editor, this scenario is typical of most dev teams who take on the challenge of building and maintaining their own WYSIWYG editor.
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.
What are the principal and interest parts of technical 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.
read MORE
Insights on the complexities of RTEs
Buy vs Build: The Great Debate White Paper
Opportunity Cost of Technical Debt White Paper
Tiny puts a price tag on building your own core rich text editor
Why does a WYSIWYG editor accrue so much technical debt?
As far as architecture, rich text editors tend to be multi-layered applications, with an editing model wrapped in a configuration layer to make a core engine. Other features can then be built on top of that core engine. This complexity often leads to rather large codebases – resulting in plenty of places for technical debt to appear (and hide).
Additionally, rich text editors aren’t standalone applications. By itself, a rich text editor isn’t very useful – it has to be used within the context of another application. That means it has to be compatible with that application – or multiple applications, depending on how it’s used – and be able to adapt to outside changes (like constant browser updates and changes).
Because of all this, developing rich text editors requires extensive domain knowledge, and that knowledge rarely overlaps with other types of applications. However, without that expertise, it can be difficult to find the right solution for many development problems.
Downsides of in-house WYSIWYG editor development
For the Attract CMS* dev team, taking on this type of complex, costly code work that's outside their core focus, produces shortcuts, low-quality, temporary-but-not-really workarounds and other hackey short-term solutions, to get through numerous launch windows.
That’s not viable in the long-term, given their plans for breakthrough growth and scaling. While the CMS may be functioning and users are currently satisfied, it can never reach its full potential until these RTE deficiencies are fixed.
If they can resolve the editor’s technical debt, its negative impact on developer velocity would be lowered, and the team's morale and output rise.
How do you measure developer velocity?
Developer velocity is a measure of the amount of work an Agile Scrum team can turn into ‘done’ (e.g., engineer hours, story points, user stories) during a sprint. At a high level, it measures how effective they are at shipping products and delivering business value.
Developer velocity formula
Velocity = Amount of done work/number of sprints
i.e. 30/3 = 10
Used as a planning tool, the developer velocity metric is helpful to different people, in different ways:
Development Team
Sprint planning
Continuous improvement
Product Owner
Release planning
Stakeholder management
Scrum Master/Team Lead
Transparency
Inspection and adaptation
However, as is the case with the Attract CMS* team, developer velocity can be distorted by the way an organization prioritizes, manages and pays down its technical debt, because it slows the progress of value delivery. This makes velocity a problematic metric – if it’s used as the sole means to measure your dev team’s productivity.
What is the definition of Velocity in Scrum?
According to Scrum Inc., “Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.
Why is developer velocity important?
Developer velocity matters because it’s an indication of the health of your engineering team. It indicates if the organization has a firm grasp on its strategic direction and the team’s consistently delivering on that business value.
While it’s best used as a tool for estimating how much time is needed to complete a task, comparisons should always be based on similar tasks previously completed. It also shouldn't be used for rating teams against each other, or as the sole metric for judging their productivity. Why? Because there are many other factors in play that affect a team's output and speed.
In answer to this, McKinsey has a wider definition of developer velocity:
“Improving business performance through software development comes down to empowering developers, creating the right environment for them to innovate and removing points of friction. Industry leaders refer to this capability as Developer Velocity.”
Accordingly, positive developer velocity occurs when developers are:
- Equipped with the right tools
- Surrounded by the right culture and environment
- Have all friction points removed
Developers can then maximize their value delivery – by innovating in their areas of core talent.
The McKinsey definition goes on to explain that when implemented and proactively managed in this manner, developer velocity minimizes barriers to productivity – thus taking a critical role in Agile development – and it drives business performance upwards.
Developer Velocity Index (DVI)
In 2020, McKinsey went a step further and developed the Developer Velocity Index (DVI) based on a survey of 440 major enterprises and over 100 interviews. They defined it as:
“...a holistic measure of a company's software development capabilities that pinpoints the most critical factors (related to technology, working practices, and organizational enablement) for software excellence. [...] companies in the top quartile of Developer Velocity Index scores outperformed bottom-quartile peers by up to five times on their 2014-2018 revenue growth.”
It was noted that organizations with developer velocity in the top quartile, achieve:
4-5 times
faster revenue growth
55%
higher score in innovation
The research also showed “that best-in-class tools are the top contributor to business success – enabling greater productivity, visibility, and coordination. [...] The underinvestment in tools across the development life cycle is one reason so many companies struggle with “black box” issues.”
By positively managing your developer velocity in the way McKinsey suggests, you can benefit through greater innovation, improved customer experience and faster revenue growth.
Plus, your software development team’s job satisfaction and retention improves, because they can focus their time on ideating, innovating and building great products – instead of battling technical debt, in complex parts of the code base – like the team at Attract CMS*.
Tech debt’s unexpected drag on feature and developer velocity
According to Gartner, infrastructure and operations leaders who can actively manage and reduce technical debt achieve 50% faster delivery times. To achieve that though, you need to prioritize and manage tech debt (and its knock-on effects) by balancing quality and speed.
In research conducted by Cisco, it was noted that “If neglected or simply underinvested in, technical debt will have negative impacts on a team’s feature velocity. A team might get away with ignoring technical debt for a first release, or even a second release, but this is not a sustainable strategy.”
In that same research, the authors' data showed “...the effects in a typical case over four successive releases. Eventually the technical debt catches up with the team. In extreme cases we have seen teams forced to spend an entire release cycle almost exclusively on trying to reduce technical debt and quality debt.”
The above bar graph clearly shows how a dev team’s feature velocity falls rapidly over successive releases, while its technical debt and quality debt rise. This then impacts their overall developer velocity, because more and more time is invested in debt reduction, to deal with the mounting backlog of technical debt items.
13 types of technical debt
When Ward Cunningham coined the term ‘technical debt’ in 1992, it only really referred to the short-cuts taken in writing code or when suboptimal design decisions were made. He likely never imagined the impact the term would continue to make, more than 30 years later.
Since then, the definition has broadened and evolved. Generally technical debt is now categorized into three main areas, in terms of software development work: intentional, unintentional and environmental technical debt.
The reality is though, that when a company takes on tech debt, it doesn’t always take the form of code or programming. Sometimes it manifests itself in other areas, such as a loss of trust and reputation, or the inability to hire new developers due to its dev work reputedly falling behind the market.
Almost ten years ago, a group of researchers from the Software Engineering Institute wrote a paper called “Towards an Ontology of Terms on Technical Debt.” In the paper, they identified 13 distinct examples of technical debt:
- Requirement Debt
- Service Debt
- Test Automation Debt
- Test Debt
- Architecture Debt
- Build Debt
- Design Debt
- Documentation Debt
- Infrastructure Debt
- People Debt
- Process Debt
- Code Debt
- Defect Debt
Given the time lapse, the rapid rate of change in software development and the digital technology now utilized, it’s likely the list would now be considerably longer. But regardless of its length, it seems obvious that baking technical debt (and its repayment) into your overall software development pipeline is now a strategic imperative.
In the end, it’s all a matter of choice: where time to market is essential, the debt might actually be a good investment, but it’s imperative to remain aware of this debt and the increased friction it will impose on the development team.
Technical Debt: From Metaphor to Theory and Practice
Philippe Kruchten, Robert L. Nord and Ipek Ozkaya
The tradeoff: developer velocity vs technical debt
Technical debt can both fuel and starve developer velocity. It’s an ongoing tradeoff between perfect products and the short timelines often required for product delivery (just ask the dev team at Attract CMS*).
1. How technical debt can help developer velocity
A team can potentially raise their short-term developer velocity by intentionally accumulating technical debt. In effect, they’re putting things off so that they can give the appearance of faster progress.
But if the team doesn’t go back to resolve the mediocre code or address known bugs, the result is cumulative interest on the initial debt.
2. How technical debt can hinder developer velocity
The long-term accumulation of debt starts to drag developer velocity down, as it makes development increasingly more difficult. That is, until engineering chooses to improve the code in favor of releasing new features, and the debt is paid off.
Because the team has a finite level of capacity, it can’t all be invested in new features or defect fixing, without incurring negative consequences. A portion of the team’s capacity must be invested in the ongoing management and reduction of technical debt, of all kinds.
Backtracking and reworking existing code can lead to developer burnout, unhappy teams and decreased productivity. Generally speaking, the more debt a team takes on, the harder it can be to maintain or control.
A 2021 survey on technical debt by Stepsize, resulted in the The State of Technical Debt 2021 Report and it noted that 52% of engineers believe that technical debt negatively impacts their team’s morale. However, despite the fact that engineers are convinced about the negative impact of technical debt, 58% of companies still have no process to manage technical 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.
Ways to improve developer velocity (and get the best WYSIWYG)
As Kai* and Lani’s* teams were learning, backtracking and reworking complex, unfamiliar code leads to developer burnout and unhappy teams, with decreased productivity and falling output. The more tech debt a team takes on, the harder it can be to maintain or control. So what’s the answer?
The trick is knowing what to build, what to buy and what specialists to tap.
McKinsey noted in their CIO interviews on tech debt, that “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.’”
Smart dev teams are now reinventing their tech debt management approach.
In doing so they reduce risk, lift morale, increase developer velocity and deliver positive value. They avoid taking on the unnecessarily complex development work like rich text editors (and its tech debt baggage) and instead buy and integrate reusable components, from specialists.
Assembling specialist components minimizes the ‘owned’ tech debt they need to carry. The debt that ‘would have’ been generated by building those complex components, is measurably reduced (if not almost eliminated).
In its place, the potential gain from on-time launches of new features is realized.
Does it work? Yes. Attract CMS* replaced their in-house WYSIWYG editor with a specialist rich text component from a domain expert, that was built for scalability. In doing that, their ‘owned’ tech debt was reduced and the domain specialist carried the tech debt load.
Buy-and-assemble components to increase developer velocity
By buying-and-assembling components, Attract* maximized the power behind third-party specialization, empowered their developers to focus on what they do best, and minimized needless technical debt.
Their dev team could then focus on being nimble enough to answer market demands for faster innovation.
Renowned software developer, author and speaker, Martin Fowler nails it when he says: “[…] while you’re programming, you are learning. It’s often the case that it can take a year of programming on a project before you understand what the best design approach should have been. […]
That’s a crucial part of reinventing your tech debt management, to increase your developer velocity. Don’t needlessly expand your own tech debt through complex builds that other specialists have already perfected.
Accept that some tech debt is best left for others to handle.
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.