“As a gamer, I wish for it. But as a developer, I wouldn’t want to be working on backward compatibility. It’s soul-crushing maintenance work, man!”
– A developer on our team who shall remain unnamed! Let’s call her Dev-I for now.
Last week, I was talking to internal Appian developers on backward compatibility (BC) when one of them shared this quote. An avid gamer and Nintendo fan, she also shared the Nintendo backward compatibility image (thanks to redditor u/rushiosan) and vehemently insisted I use this in the blog. So here you go, Dev-I.
Dev-I’s position isn’t new.
Many developers can’t stand any software maintenance work because maintaining code is boring.
To me, it is similar to having the capability to build and send a rocket to Mars but instead you spend most of your time doing maintenance on a rocket from the 90s that may or may not fly again (It’s the Aerospace Engineer in me talking!)
But why is maintenance so hated? The answer lies somewhere between 306 million hours, loss of productivity and lack of recognition.
This blog gives two perspectives - our mysterious Dev-I who can’t stand maintenance work like backward compatibility and our Product Lead who is making life easier for such developers.
There is no ‘Main’ in maintenance work
Source: https://stripe.com/files/reports/the-developer-coefficient.pdf
On average, developers like Dev-I spend 17 hours per week on maintenance work. With 18 million developers around the world, that’s a grand total of *checks calculator* 306 million hours per week spent on maintenance globally.
Three Hundred and Six Million total hours. On things like code refactoring, enhancements, migration….and backward compatibility.
No one is questioning the importance of maintenance. But as the not-so-aptly named uselessdev from uselessdevblog puts it in this article, the choice is always between delivering value or delivering maintenance.
The less you focus on maintenance work, the more tech debt you accrue. Companies understand this but often don’t invest enough time or money into maintenance. Because business is all about creating value, right?
“My employer pays me to focus on delivering value. But this gets you into the “tech debt” zone. There’s no incentive to pay people to tackle tech debt” – uselessdev
Maintenance is never the main attraction of being a software developer. Developers like Dev-I didn’t learn coding with grand dreams of doing code maintenance.
Backward compatibility: Rewarding to some, repetitive to others
Some maintenance work – like backward compatibility – has the potential to be rewarding.
Just ask the team behind the Xbox backward compatibility. The new Xbox Series X is backward compatible across four generations of Xbox, delighting gamers around the world (unless you are Dev-I and a Nintendo fan).
Put any old Xbox game into the latest console, say a couple of prayers (optional), get misty-eyed with nostalgia and start playing. It’s. That. Simple.
This is delivering a game-changing customer experience. This thrills millions of Xbox users around the world. This is maintenance work that gives direct recognition to the developers.
Source: Windows Central
But not all backward compatibility work is rewarding or interesting, especially in Dev-I’s world of low-code software.
Backward compatibility in low-code (or how we keep Dev-I happy)
The brutal reality of all B2B enterprises is that, more often than not, they need to reuse data and applications created with an older version of the platform. The oldest Appian application that still runs is from 2008. Dev-I was still in high school then. She could be asked to integrate that app into one from the latest version. We see this with our customers often.
Perhaps this is why Appian has a simple backward compatibility promise like Xbox. “Backwards compatibility is often what keeps me happy and free from the ‘soul-crushing’ work”, says Dev-I.
By making sure old features and applications work even better when upgrading to a new version, we eliminate the boring, repetitive, manual work for developers everywhere.
For the engineer in me, this was too good to be true. But when I went over to the Appian Community to see what our users say about backward compatibility, I noticed this response from Stefan Helzle, Manager at a multinational professional services company.
No issues since 2010 with backward compatibility? That’s quite a ringing endorsement.
“We suffer so you don’t have to” – A Product Architect’s take on backward compatibility
I spoke to Matt Hilliard, Product Architect for the Appian platform, about our backward compatibility. Matt’s an OG developer who started out coding in Java in 2003 before focusing on low-code. If anyone could explain our commitment to backward compatibility in detail, it is Matt.
“We’ve built our entire internal process on the Appian platform. Before any customer gets the latest release, our critical apps are already running on the new version. If we screw up with backward compatibility, we hear it first internally”, says Matt.
“We do extensive regression testing to ensure existing apps work. In a way, we suffer a lot to avoid our customers suffering a bit”.
We have 100s of internal apps to run our business, all built on Appian. If something doesn’t work in a new version, you can be sure Matt’s team of developers will hear about it non-stop before it’s released to the public.
In Matt’s words, there are a few key principles to offering unparalleled backward compatibility.
Any usage of a feature – no matter how small – we keep it and then work on improving it
Have comprehensive automated regression testing and internal usage of the platform
Only expose features/settings that customers absolutely need since we honor them for years
Always hotfix the rare backward compatibility bugs that slip past our quality checks
“Bugs happen. Mistakes happen. Behavior changes happen. That’s how new versions go”, says Matt. These developers sure are a pragmatic lot.
“So we make a corporate commitment to always hotfix backward compatibility issues, no matter how subtle it is or how few customers use it”.
Building for the developer
If you build public mobile apps - the ones you buy in mobile app stores, you are at the mercy of the tech companies for updates. You update when and how they want you to.
But for Appian, application developers like Dev-I are our customers. We can’t push around the developers.
If you build on Appian cloud, the upgrade to newer versions is automatic and seamless. But if you don’t, we have a commitment to make it as seamless as possible for the developers.
With four releases every year, the only way to do this is to offer full backward compatibility.
As of last count, there are over 2000 Appian Developer jobs available today on LinkedIn worldwide.
That’s over 2000 new developers entering organizations having to deal with data and apps from before their time. And I’m not even counting the thousands of Appian developers who are dealing with that today (Looking at you, Dev-I).
With backward compatibility, we want to give developers like Dev-I more time back in their day for greater intellectual pursuits, be it building cool new code or playing the Nintendo Switch.
For the curious developer
You can read all about the philosophy of how Appian builds for backward compatibility here.
But I know you developers are a curious lot. So I invite you to take Appian for a test drive in Appian Community Edition, a free environment where you can explore Appian.
Pick one of the courses from the ‘Builder’ persona and give it a try. Maybe wait three months for the next version and check the backward compatibility for yourself while you’re at it.
