Every company I have ever worked for had some. Few seemed to want to deal with it, and even fewer were confident they could. Legacy Code is a fairly consistent, and strongly pejorative term within software development. But, is that a good thing? Over the last several years I have come to think that it is not. And, after hearing Chad Fowler present his keynote at RubyConf 2017 titled “Growing Old,” I have been reinforced in that opinion.
Defining a Legacy
One of the big themes that I took away from Chad Fowler’s talk was the reminder that in every other field of endeavor the idea of Legacy is a good thing. A legacy is typically thought of as a gift left by prior generations. Sometimes that gift is knowledge, or money — Yet, in the realm of software development the notion of what is left from one generation of programmers to another is very rarely viewed in a positive way.
In one sense, this can be understandable given the rapid pace of technological advancement and the way certain tools and techniques can become antiquated. But, in many businesses the legacy systems are still delivering value, and often in a predictable way. But, our perspective as programmers, developers, or engineers is rarely centered on value.
Selfishness & Novelty
Instead of looking at the value that is delivered by these existing systems we tend to focus on how hard they are for us to work in. Sometimes we grip about the frameworks they rely on, or the patterns an approaches taken by former caretakers. Sometimes we complain about the tangle of code that is hard to decipher. And, sometimes our criticisms have merit. But, as I reflect on my own career, more often than not, I was usually just being whiny.
Two contrasting examples spring to my mind, one from the mid-point of my career where I feel like I helped my employer make a good change, and another from a little earlier in my career where I’m less confident I made the best long-term choice for my employer. I’ll start with the case where I think I did well.
A Success Story
Several years ago I was working for The Ready Project. I had the opportunity to run into my former boss a couple days ago. I was glad to hear that, after a couple years of contraction across their whole industry, things are starting to stabilize. When I started working for them they were running an e-commerce site on Magento that was costing a substantial amount of money to maintain performance and availability. After getting a good understanding of how they were maintaining inventory synchronization with some third-party fulfillment partners, and their own warehouse; I encouraged them to make a switch to Shopify.
The monthly costs were about the same at that time. Switching to Shopify offered an opportunity to freeze the operational costs at a predictable level that we could not do with Magento. So, we contracted another firm to do a coordinated redesign while I built the inventory integrations with Shopify. After a few months we were able to launch and they are still running on Shopify. I ended up having to leave as a part of the industry contraction that effected the business, but I’m proud of a lot of the work I did for The Ready Project. It put them in a position where my role was not essential and even without my technical abilities they were still able to go on with their business.
A Lack of Forethought
The other example is from a couple years prior to my time at The Ready Project. I was working with a marketing and design consultancy doing implementation work for web sites they designed. Like many companies in that space they delivered sites with Content Management Systems (CMS) to allow clients to manage as much of their own sites as they felt comfortable with.
The year prior to me starting with them I had begun doing a lot of work with Ruby, and was starting to learn about Ruby on Rails. In that process I came across a CMS built on Rails that was absolutely great for me to work in and build extensions for. I built a lot of fun to work on custom extensions. But, that was not the work I should have been doing. I delivered my work on time, but not always in a sustainable way. That made the job really stressful for me. The problem was that I had chosen to do work that was fun for me, but wasn’t necessarily good for the business.
I should have chosen tools like Drupal, or WordPress, and focussed effort on minor customizations, rather than creating thoroughly custom solutions. There would have still been products that made sense to use my Rails-based CMS, because it was much easier to work with than Drupal or WordPress at the time. The problem was I was not thinking about the long-term ramifications of my work. I was not thinking about what would come after I eventually left. I don’t know if anything I built while in that role is still running today.
Check Your Motivations
The problem in the latter case was that I was focussed on myself and what I wanted to do. I cared about my employer and their success, but I wasn’t taking the long-term view. That was a pretty good time ago now, and I’ve learned a lot since then. But, there were decisions I could have made that would allow me to feel better about the legacy I left there. In the time since, including my time at The Ready Project, I have gotten much better at thinking holistically about my employer and less about myself. So, my motivations have shifted subtly. I now am less worried about padding my resume and instead want to do what I can to make sure I am doing what my employer needs to be successful. I am applying my experience in different ways, and not all of them are technical. That is a big reason why I don’t care as much for chasing the newest tech. I want to understand it, but using it is not my priority. That decrease in selfish motivations makes me a better employee, at least in my estimation.
Back to Legacy Code
So, what does any of this have to do with Legacy Code? Well, first, Legacy should not be a pejorative. In many instances the code is working and producing business value. Can the same be said for whatever else is being actively developed; all of it? I doubt that answer in many businesses is a overwhelming and defensible affirmative.
Working code is better than code that does not yet exist, work, or produce value.
Legacy code was produced by people who we should assume were doing the best they could with the resources and information they had available. We may not like the output, but we should appreciate the effort. We should respect the work that went into the projects. And, we should look for ways to improve it when possible, retire it graciously, and speak well of those who managed to deliver business value that we are today working to build on top of.
Top comments (0)