Blueprint by Tiny
Return to Tiny.cloud
Return to Tiny.cloudTry TinyMCE for Free
Search by

developer insights

Is your code half-life shorter than your engineering career?

Published November 9th, 2022

Arthur Wright* retired from his engineering career at 65. His son, Terry*, loves the tech sector but at 30 he’s calling time on his lead engineer role at Ardalion*. Like many tech engineers today, Terry is struggling to match the constancy of change. Why? Because the half-life of his knowledge and skills are shrinking almost as fast as the code half-life of the software he’s writing. He can’t keep up.

Di Mace

Marketing Communications Manager at Tiny


"Six years at uni, for a six-year career," Terry said to his colleagues on his last day at Ardalion*. His fellow engineers nodded and felt the same weight hanging over their future. It’s the new norm and an unsettlingly recurring pattern in a profession that was long known for its job security. Engineering was once a safe place: until technology arrived.

Then a master's degree became little more than ‘a base’ for continual extensions and modifications.

In an era when the code behind today’s high-tech gear becomes outdated as fast as milk and yogurt, software developers know they have to keep improving their skills and the code they’re writing, or risk broken apps that nobody buys and massive tech debt burdens.

Let’s see how half-life was affecting Terry Wright’s* life.

What’s the half-life of knowledge?

The ‘half-life of knowledge’ is an expression coined in 1962 by economist Fritz Machlup, to describe the time it takes for half the knowledge in a particular domain to be superseded. It draws an analogy with the half-life of radioactive decay (see sidebar) to describe how over time, accepted knowledge and ideas are reinvented or improved.

Everyone agrees, it’s been steadily dropping across numerous professions.

In engineering, a 1966 story in IEEE Spectrum titled 'Technical Obsolescence,' proposed that the half-life of an engineering degree in the late 1920’s was about 35 years, whereas a similar degree from 1960, was thought to have a half-life of about 10 years.

Then Thomas Jones’ 1966 paper entitled ‘The Dollars and Sense of Continuing Education’, calculated the effort required for an engineer to stay up to date, assuming a 10-year half-life. The 1966 calculation came to at least five hours per week, 48 weeks a year, that needed to be devoted to stay up to date. That’s obviously drastically multiplied in the half decade since.

A 1991 New York Times article, 'Engineer Supply Affects America', cited the same 1966 IEEE article when it reported the half-life of engineering skills was then estimated to be under 5 years, and for a software engineer, it was less than 3 years.

In 2002, William Wulf, the president of the National Academy of Engineering, was quoted as saying that, "The half-life of engineering knowledge, the time it takes for something to become obsolete, is from seven to 2-1/2 years." While Stanford Professor, James Plummer’s, 2017 address to the first IEEE Summit said “Careers are becoming global and unpredictable. [...] Lifelong learning is essential. The half-life of engineering knowledge is three to five years.”

It’s those shrinking numbers, that haunted Terry Wright’s* career.

Code has to keep up

While Moore’s Law may have decelerated (see sidebar), there’s still exponential growth and progress happening across technology. But it’s no longer just hardware.

Software and frameworks have improved, and distributed processing (via the Cloud) is available to virtually everyone. While that may not speed software up per processor, it does mean you can do more with it. And it must be accessible anywhere, to do anything, on any device.

So your code has to be high quality to manage the load. But some code decays faster than others.

*Company and personal details are fictional, but indicative of the issues related to building and maintaining a functioning rich text editor and advanced features.

What’s half-life?

A half-life is the time taken for something to halve its quantity. It's usually related to nuclear physics and describes the rate of decay of radioactive material.

The discovery of half-lives (and alpha and beta radiation) is credited to New Zealander, Ernest Rutherford, one of the most influential physicists of his time. Archeologists and geologists also use half-life to date the age of organic objects in a process known as carbon dating.

Rich text editors live a fast life

Wright* led a team of developers that worked on their custom-built internal document management software, which relied heavily on a rich text editor (RTE) for its advanced features and functionality. His team had heroically built the editor six years ago, when they launched the application, but since then had struggled to keep up with the increasing demands of its users.

Now Ardalion* wanted to launch a SaaS version of the software.

A rich text editor is a crucial component within every organization’s tech stack that enables rich text editing capabilities within any application – no matter the type, use case, or device.

However, it’s not only the main editor’s initial coding and subsequent refactoring that needs to be done. Each individual plugin (feature), every linked service, library, or tool, as well as browser changes and APIs, need to be monitored, reworked, and maintained.

It’s a flywheel in constant motion.

In hindsight, Wright* now knew that the crucial 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 was generating a massive technical debt that his team had to constantly (and begrudgingly) work on. For rich text editors, coding new functionality to match upgrades and features in other applications (and to stop breakages), is an endless cycle.

Most rich text editor specialists have large teams of developers who work on them year-round. And that's all they do. They know when and why it's the right decision to take on tech debt and at what point to start paying it down – so that product development, scaling and feature improvements don’t slow.

The naivety of building their own rich text editor, was now threatening the Ardalion* SaaS launch.

Tracking technical debt in a rich text editor – and even more importantly, identifying areas that likely have tech debt – is very difficult. And it's costly. But surely there’s indications?

And here is where Terry Wright’s* half-life of knowledge and skills, and his RTE’s code half-life, intersect.

What’s Moore’s Law?

Moore's Law states that the number of transistors on a microchip doubles about every two years, though the cost of computers is halved.

The theory, posited in the 1960s by Gordon Moore, the founder of Intel, implies that chips continue to get faster and cheaper at a predictable rate.

After fifty years of being the golden rule for the electronics industry, there is now ongoing debate whether the theory is still active.

Get more insights in our
Technical Debt White Paper

READ THE WHITE PAPER

What’s code half-life?

Software developer, Sandi Metz, defines the code half-life phenomenon as “the amount of time required for half of an application's code to change so much that it becomes unrecognizable.” That definition emerged after watching Dan North’s Software that Fits in Your Head talk, where North tells the story of a complex application he worked on, whose code half-life was a mere six weeks.

Code half-life eats at every developer’s work and increases the technical debt your app is accumulating. And in a rich text editor, the technical debt is further increased by the code complexity, its dependencies, libraries and browser updates.

In my experience, most applications are a mess. Successful businesses rely on long-lived applications that endure a constant barrage of new requirements. Changes are commonly made under urgent time pressure, which drives applications towards disorder.

As entropy increases, it becomes harder and harder to add features except by way of one more hack. The accumulated mess leads to hacks, hacks lead to more hacks, and then you're in a loop. Velocity gradually slows, and everyone comes to hate the application, their job, and their life.

Sandi Metz

Software Developer

For developers like Wright*, when both your code-specific knowledge and the code itself have short half-lives, it’s not so much about documenting and protecting your secret sauce, it’s about how fast you can learn something new, and how easily you can let go of the old.

That's what wins the battle with the competition. And keeps you happy in your job.

The speed of change in rich text editors generates tech debt

Code doesn't ever really die. But it does decay.

The key role that code half-life can play when reviewing a complex code base, is as an indicator of ‘potential’ technical debt.

While it's a given that untouched code, after enough time, probably needs work… potential tech debt is tricky. It isn’t always clearly visible (until you try to read the code) and can give false impressions about the quality and quantity of the product development and/or incremental work being considered.

Erik Bernhardsson’s ’The half-life of code and the ship of Theseus’ article and ensuing Git of Theseus project, explore the conundrum of code half-life and question “...does the new code just add up on top of the old code? Or does it replace the old code slowly, over time? [...] There is a ‘Ship of Theseus’ effect, but there's also a compounding effect where codebases keep growing over time.”

This highlights a key aspect of building, maintaining and scaling a rich text editor: its code has a very short half-life. Let’s see what that looks like.

What’s the Ship of Theseus?

The Ship of Theseus, also known as Theseus' paradox, is a philosophical thought experiment. It considers whether an object that has had all of its original components replaced, really remains the same object.

It hales from an ancient Greek legend about Theseus, the mythical Greek founder-king of Athens, and the ship he used to rescue the children of Athens from King Minos after slaying the minotaur.

Get more insights in our
Technical Debt White Paper

READ THE WHITE PAPER

Rich text editor half-life projections

These maps are generated using the Git of Theseus project, and the code repositories of an advanced rich text editor and its plugins.

Core editor code half-life stack chart

The Code Half-life in a Rich Text Editor: Lines of code, by yearly cohorts, across 5 years

This first graph (above) plots across 5 years, the aggregate number of lines of code in a rich text editor, broken down into cohorts by the year added. It clearly displays the number of sweeping changes needed to maintain the editor’s competitive position in the marketplace.

Core editor code survival chart

The 5-year Aggregate Decay in a Rich Text Editor: Individual commits in a repo, by yearly cohorts, across 5 years

Next is the aggregate decay for individual commits in the RTE’s core editor repo (see above). After 5 years, only 30% of the original code remains. The rest has been refactored, upgraded, repaired or replaced.

only

30%

of the original code remains after 5 years

The editor in question is more than two decades old and has undergone massive resets over that time (switching to TypeScript, rewriting the whole UI and a DOMParser change), yet in the last five years both small incremental changes and large sweeping resets were required to manage the RTE’s technical debt. That’s a considerable amount of payoff tasks (upgrading, refactoring, repairing) to be done, every year.

Much of the technical debt accrued by a rich text editor, is driven by the code complexity, its dependencies, libraries and browser updates. New features are also in constant demand.

Let’s now see what the half-life of the code used in some advanced rich text editor plugins looks like when it's mapped.

Code half-life projection: Advanced Case Change plugin

These maps are generated using the Git of Theseus project, and the code repositories of an advanced rich text editor and its plugins.

Code half-life stack chart: Advanced Case Change plugin

The Code Half-life of an Advanced Case Change plugin: Lines of code, by yearly cohorts, across 10 years

This first graph (above) plots across 10 years, the aggregate number of lines of code in an advanced case change plugin, broken down into cohorts by the year added. It clearly displays the number of sweeping changes needed to maintain the plugin’s competitive position and update various dependencies.

Code survival chart: Advanced Case Change plugin

The 5-year Aggregate Decay in an Advanced Case Change plugin: Individual commits in a repo, by yearly cohorts, across 5 years

The next graph (above) represents the decay of the connected repos of an advanced case change plugin, where just around 35% of the original code is left after five years.

only a

3.94 year

half-life for an advanced case change plugin

And (below) fitting an exponential decay and solving for the code half-life of the same advanced case change plugin gives 3.94 years years.

The Exponential Decay in an Advanced Case Change plugin: Individual commits in a repo, by yearly cohorts, across 5 years

Code half-life stack chart: Advanced Link Checker plugin

These maps are generated using the Git of Theseus project, and the code repositories of an advanced rich text editor and its plugins.

The 3.5-year Half-life of an Advanced Link Checking plugin: Lines of code, by yearly cohorts, across 3.5 years

This next graph (above) plots across 3.5 years, the aggregate number of lines of code in an advanced link checking plugin, broken down into cohorts by the year added.

Code survival chart: Advanced Link Checker plugin

The Exponential Decay in an Advanced Link Checking plugin: Individual commits in a repo, by yearly cohorts, across 5 years

This graph (above) represents the decay of the connected repos of the same advanced link checking plugin, where only 25% of the original code is left after five years.

only a

2.13 year

half-life for an advanced link checker plugin

And (below) fitting an exponential decay and solving for the code half-life of the same advanced link checking plugin produces a tiny 2.13 years years.

The Exponential Decay in an Advanced Link Checking plugin: Individual commits in a repo, by yearly cohorts, across 5 years

All these maps clearly show there’s lots of ongoing maintenance work and ‘potential’ technical debt lurking in just about every rich text editor and plugin. Which means, the payoff tasks for editors are endless.

No matter how perfectly the original code was written.

Get more insights in our
Technical Debt White Paper

READ THE WHITE PAPER

Knowledge is replaceable

In his 2013 book, The Half-Life of Facts: Why Everything We Know Has an Expiration Date, author Samuel Arbesman proposed that facts decay over time until they’re no longer facts, or perhaps they’re no longer complete. Put simply, over time, one group of facts replaces another. And it seems there’s no shortage of examples to validate his theory – Pluto isn't a planet, dinosaurs had feathers, and there’s 46, not 48 chromosomes.

But it places many professions at a crossroads, especially technology engineering.

As both the tools and knowledge become more advanced, developers must continually discover new things that contradict what was thought to be known, or replace them with upgraded nuances about old things. Sometimes you even have to learn a whole new area that you didn’t know before.

Given the rapid pace of technological development, the half-life of engineering knowledge is now said to be less than 2 years. More and more new knowledge needs to be constantly learned, over shorter and shorter intervals.

Which is the point where Ardalion* and Terry Wright* parted ways.

Approaches are changing: don’t build, buy-and-assemble

Smart dev teams are reinventing themselves, in innumerable ways.

That includes their approach to code half-life and tech debt management – so they can reduce risk, lift morale and deliver positive value. They avoid taking on unnecessarily complex development work (and its tech debt baggage) and instead buy and integrate reusable components, from specialists.

Does it work? Yes. Assembling maximizes the horsepower behind third-party specialization, empowers developers to focus on what they do best, minimizes needless technical debt and delivers the nimbleness to answer market demands for 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 development work and engineering career. Yes, keep learning new things, but only where and when its half-life is longer than its usefulness. In software development, both knowledge and code are rapidly changing, so your competitive advantage partly lies in having the best quality and most valid forms of both those things.

Hanging on to old stuff that’s past its half-life can be competitively dangerous.

It boils down to the faster the speed of change, the shorter the half-life and the greater risk of obsolescence. That’s the well-worn wisdom that Arthur Wright* shared with his son, Terry* when calling time on his career.

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

  • Developer Insights

    Managing technical debt is difficult in rich text editors

    by Millie Macdonald in Developer Insights
Subscribe for the latest insights served straight to your inbox every month.

Deploy TinyMCE in just 6 lines of code

Built to scale. Developed in open source. Designed to innovate.

Begin with your FREE API Key
Tiny Editor
Tiny logo
Privacy Policy - Terms of Use© 2022 Tiny Technologies Inc.TinyMCE® and Tiny® are registered trademarks of Tiny Technologies, Inc.

Products

  • TinyMCE
  • Tiny Drive
  • Customer Stories
  • Pricing