In your organization right now, do you have old software running a core piece of your business? Maybe it’s an older Java monolith application, .NET Full Framework WCF service, or even AngularJS. Who knows? The possibilities are endless really. And our industry has several common names for this: technical debt, legacy systems, etc. At this point though, I feel like those phrases are all but worn out in our industry. I cringe when I hear others use it. I shudder when I let the words pass through my own mouth in front of executives. When coaching others, I introduce an alternative phrase: technology enablement.
If we can’t quantify to a non-technical person why replacing or refactoring a piece of software will enable speed, agility, quality, and/or business opportunity, it’s frankly not worth discussing. We need to have these conversations and state what investments in replacing or refactoring a system will deliver to the business (and by when, which is a separate blog article). We should also be prepared to be told no. Sometimes legacy systems are legacy because the value stream to the business is dying off and will be spun down in the future. However, if there’s an opportunity to achieve The Rule of 40 by replacing a legacy system, point it out. It’ll be a more effective argument than more traditional conversations I hear during my day-to-day.
As an example, I wouldn’t let my car mechanic work on my car for no perceived reason. My mechanic can tell me ad nauseum about all the dangers, but I wouldn’t budge until I really understood the risk. If fixing my car means it will give my mechanic the warm and fuzzies the next time he works on my car, or it will make it easier to work on my car next time, I’m not budging. If I’m told repairing my car will help it last longer, get me better gas mileage, and enable me to drive it for longer… now we’re talking. It enables me to do other things I want, namely avoid a new car payment.
Therefore, in terms of enablement, I want to make an argument I don’t hear too much in our industry. It goes beyond agility, features, or even quality. And while those are important, they aren’t human. It’s one factor I think is worth discussing but usually left off the table during these talks. Older technology is more than just a technical problem or even an agility problem. I posit it’s a talent problem and can even become a recruiting problem. An expensive recruiting problem at that. Let’s take the most egregious example I like to use to make my point.
NASA’s Voyager I and Voyager II spacecraft are still in operation today and launched more than 40 years ago. These spacecrafts use old hardware running with software written in legacy languages such as Assembly, FORTRAN, and others. I remember reading articles several years ago about NASA’s difficulty recruiting FORTRAN or Assembly developers. This isn’t a shock either. Who wants a COBAL job these days? Further, a cursory Google search also shows developers with this skillset can be quite expensive to employ. And while this example is borderline ridiculous, it serves to prove a point. If you need developers that know an arcane technology by today’s standards, you are drawing from an ever-decreasing talent pool with an ever-increasing rate. And why is this a big deal? As a business, we want our top-level talent working on the hard things, not maintaining old systems.
Employers should seek to bring in the best talent available. In No Rules, Rules by Reed Hastings (CEO of Netflix) and Erin Meyer, they ran an experiment comparing top engineering talent to average talent during their interview processes. The top developers were 20 times faster at coding, 25 times faster at debugging, and 10 times faster at programming execution than their average counterparts. That’s not something that can be dismissed. Really pause and let those numbers sink in. Top performers run circles around their peers. Imagine what a business could do with 20 times the productivity of their competitors. When top talent encounters a legacy system they don’t want to work on, they should be allowed to refactor or re-write them. If they aren’t allowed to enable the business through a little nurturing of an older code base, they may get antsy and leave. Afterall, why should they stay? They’re the best at what they do, and as such, can get a job most anywhere. If they leave then turnover will be the next issue to arise.
Look up what a high turnover rate can do to the morale of an office. It can be devastating to an organization. For what it’s worth, I also see similar results at my clients when key employees leave. While morale can improve over time, it takes attention away from growing the business. Time and energy have to be spent aligning different groups within the organization and rebuilding trust with those remaining. In the end, not addressing legacy systems will cost the business one way or another, and when people are hamstrung with legacy systems, the business will potentially deal with the issue without their best and brightest on board.
In summary, as we discuss legacy systems with our business-minded folks, we should accentuate enablement around modernizing legacy systems instead of framing the conversation around cleaning up technical debt. Scrub technical debt from the conversation as much as possible. Put another way, the business should know what they get in return for their investment. What we get out of it doesn’t really matter. Further, discuss the very real human side of this equation when deciding how to proceed. Hindering your best and brightest could mean paying top dollar for a replacement and lower morale of staff dealing with high turnover. If I had to pick a dangerous road to travel, I’d rather go down the road with my best people at my side.