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

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.

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.

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.

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.