Will your entire career be technical debt?

Matt Watson, AKA The Visionary CTO, has a thought-provoking post recently: "My 20 Year Career is Technical Debt or Deprecated."

It's a good read and I recommend it highly.

Short version is that Matt's career began in the 90s as a Visual Basic 6 programmer, then moved to other now-legacy languages like Perl, FoxPro, Cold Fusion, Flash...the list goes on. 

His view is that all that code is dead, becomes a zombie, or is technical debt. All code rots, he says. 

This is not too different from the John Browne rule: All code is s**t. Eventually anyway. 

My entry to software was using punch cards and coding forms. When I got an IBM 3270 terminal, I was thrilled I could code COBOL on a screen with super hot features like backspace and delete/insert. Debugging was still "PRINT" statements however. Compiles still happened overnight at the remote datacenter. 

Oh how things have changed. 

You could argue that back in the day when it was REALLY HARD to write and debug programs, we had to be more thoughtful. But I think that's probably hogwash. Developers--programmers--are people, and like everyone else they come in all flavors. Some are methodical, careful, and think every change through from a full system standpoint. Others (looking at you JB) see a bug and fix it. Maybe the fix is good, maybe the fix is bad, but NO TIME so move on and get it working. 

My slap-dash style was one of the main reasons I didn't choose to pursue programming as a full time profession. Undoubtedly someone would have eventually hunted me down and served me up for past sins.

But--back in the day--that 3270 terminal was a Godsend. It allowed me to hack out some Q&D business apps that have long since been sent to the boneyard. About the same time I got my hands on a 8080-based microcomputer with VisiCalc and it made my annual departmental budgeting circus ("Now cut another 8%") a breeze compared to my buddies who were still using pencil and calculator.

3270 COBOL and VisiCalc are laughable today. So is Perl, Ruby, VB6, Flash, Cold Fusion, ASP.NET Web Forms, and countless other Things That Were Once Awesome. 

It's all technical debt. 

I was lucky enough to be in the Languages Business Unit at Microsoft in the 80s and 90s and watch the evolution of  programming languages, platforms, and tools--especially tools--from command line to character windows (anyone remember QuickBasic or the M Editor?) to Windows UI and OOP like C++. 

Each iteration felt like awesomeness at the moment of release. Later, looking back, we see them for what they were, even through our nostalgia. 

Not everything old is bad, and not everything old is good either. Sometimes you can take an old thing and modernize some of it, keeping the value but making an improvement. Some old things people prefer to modern ones, like my century-old #4 Stanley smoothing plane.

Legacy software, some argue, is by definition technical debt. Windows Forms applications, for example, can be pretty old but still running on supported platforms (.NET Framework or Core) and C#. It's possible that, with on-going maintenance, these are free of technical debt. Not likely, but possible.

If you have legacy software that you consider to be technical debt (ie old, crappy, but necessary), you have three choices other than kicking the can down the road for your successor to deal with: replace it with Salesforce, Sharepoint, or some other off-the-shelf system, heavily customized; rewrite it from scratch, or modernize it. 

If you've ever done a Salesforce or Sharepoint install and customization, you already know that you're going to be writing code--procedural and functional--within the limits and UX of the platform. Then you have integration with 3rd party apps to get point solutions for individual requirements. Lashing all that together--and paying the subscription fees--can make you think writing the app all over again from scratch might be less trouble and overall cost. After all, you don't have to pay a monthly subscription fee to license your own code, do you?

A rewrite can be attractive on the surface, but is it the right way to clear out that accumulated technical debt? 

Green-field development means you can choose your front-end framework, programming language, back-end server platform, full-on modern architecture with serverless functions, microservices, middle ware: basically anything you want. 

And therein lies the problem.

Here's the reality: upwards of 70% of new software development fails to hit the schedule, budget, or user expectations. It's beyond hard, regardless of which version of Agile or Waterfall or NinjaScrum.com you're using. I DO hear from customers who successfully rewrite their old desktop apps, but invariably they are small, simple things with manageable requirements and schedules. The other rewrite approaches we hear are the following:

• They've done it in the past and would rather have root canal surgery without anesthetic than do it again
• They tried it and kept failing and finally gave up (I've personally witnessed two of these)
• Their app is of such a size and complexity that a rewrite is functionally impossible.

One CIO (who happens to be a customer of ours) actually did the experiment to compare a rewrite with automated migration. You can read the results here. TL;DR: rewrite was much more expensive, and the final costs were a multiple of the initial plan. 

One final note: migration can get you clear of many kinds of technical debt, but not all of them. You can modernize the language and runtime platform, possibly the architecture. Some stuff will remain the same: weak algorithms, copypasta code, crappy comments (if any), functions with multiple jobs, etc. But a migration can be a first step in a full-on technical debt clean up, because you can work your way through all those remaining issues one at a time. 

And, if you're lucky, you just might get caught up right before you retire.