Today, I'm just flabbergasted. Hundreds of thousands of passengers have had their flights delayed or canceled. And the worst culprit, Southwest Airlines, experienced disruptions due to issues with its outdated scheduling infrastructure.
Today, we can do amazing things with technology (as we've seen with Open AI and more). But how many developers at Southwest warned managers and the executive team that they needed to upgrade their legacy system? What we do know, they have been warning leadership about this system for years!
Here is what I bet happened at Southwest. A developer saw the writing on the wall and warned an engineering leader. That engineering leader brought the issue up with a product lead, a senior leader, or even the CEO. However, they didn’t have the same pictures in their heads as the engineers, so they didn’t “get it.” Why refactor when it’s working just fine today? And there lies the disconnect! When the decision maker stack ranked this versus other priorities, it didn’t seem to have the same weight as “make Southwest the biggest and best airline.” So they told the engineering team, “maybe one day.”
Many of us have found ourselves in this exact situation, though maybe not on the scale of Southwest Airlines. This happens because the developers don’t have a way to visualize the complexity hidden in their code — they lack code visibility tools. Because they don’t have visibility, business people or senior leadership or anyone else who doesn’t spend time in the code everyday, have an even worse picture. As a result, refactors like this don’t get the resourcing they need or prioritized, until one day you have a Southwest-sized crisis.
This is why it's my life's work to build CodeSee.
As a dev and former product leader, my team and I are creating fantastic code visibility tools for developers. I can’t help but say this… don't be Southwest. Sign up for CodeSee.io. CodeSee.io is a platform that helps software teams visualize their code before a complete meltdown happens.
The complete meltdown of software makes me very sad.
The truth is this: sometimes we fail at refactoring legacy code or convincing executives that we should or how this massive change gains business value, despite everybody having the best intentions. Why? Because the size and complexity of our codebases are massive, with poorly understood dependencies, lack of documentation or understanding of the code, and a big risk of breaking existing functionality.
Despite this, below are my tips on making yours work:
Tip 1: Get visibility into your codebase any way that you can so you can understand how your code works
If you don’t have a code visibility tool, write down everything. It’s annoying and time consuming but writing everything down can will get past any security team and managers will never balk at it for taking additional time outside of writing code. It’s not expensive and it will come in handy for everyone when your team experiences the outage or meltdown.
Tip 2: Keep a running catastrophe list
Keep a list of potential problems and how they connect to other parts of the system. If something goes wrong you have a list of the things that will be impacted and you know what to prioritize.
Tip 3: Make diagrams
Pictures are worth a thousand lines of code. Most people who aren’t developers don’t speak the same language as a developer. Business executives, sales leaders, product managers and more can understand pictures. It takes more time for a developer to draw out a system, but it takes less time for a business exec to grasp a picture.
Tip 4: Tell stories
When trying to get your refactor or your system upgrade accomplished, tell a story. Better yet, tell a story that will resonate with the picture in the other person’s head.
Stuart Diamond, author of Getting More, says “The outcome that you’re striving for will be improved when you start thinking from the other person’s perspective. What are their needs or fears? How are they approaching the situation? These are critical pieces of information for any successful negotiation.” Have a little empathy for the other person and explain your goal in concepts that they will understand. If that fails, you can say, “We have a problem just like Southwest. Let’s not be Southwest.”
Tip 5: Don’t try to do everything yourself
Sometimes people need to hear the same story from multiple people. Have you ever told your spouse one thing and they don’t get it, but suddenly they hear the same thing from their best friend and it clicks? This isn’t their fault or the executive's fault, but when you are trying to get your refactor done, use this to your advantage.
Tip 6: Create a plan
If you want to get the refactor accomplished, go ahead and create a draft plan. If you can, create a few options: a min viable, an acceptable, and an ideal plan. In your spare time, code dive to list the holes, potential problems and connections that will need to be changed to make your refactor a reality. It doesn’t need to be perfect, but arm yourself with the information needed. For good measure, combine your draft plan with your diagram from tip 3 and your story from tip 4 to increase the chance of your plan really having a visceral reaction.
Tip 7: Learn to manage upwards
I learned this in my years of working with leaders, particularly CEOs. When you get to the top, there is a lot of anxiety and pressure on everyone.
Managing up is all about managing the other person’s anxiety. If you know what the person is anxious about you can provide a calming effect when you bring this major problem to them. This will allow your message to be received a bit better.
Don’t just bring the problem to your manager. Bring the problem, plus the options for a solution. Make them feel like you have everything taken care of and all they need to do is sign off on the plan they like the most. That means, consider downstream effects... not: we’re going to stop all development for the next 6 months — cause no one is going to sign off on that. For more on managing up, see my managing up blog posts for developers.
Tip 8: Automate
When in doubt, automate, find some time to automate rules about your codebase.
Tip 9: Write comments
When all else fails at least leave some comments about the WHY of the code. In a crisis, absolutely no one has time to read your self documenting code and the code is never self explanatory.
I know you might be thinking, “my company doesn’t pay me enough for this.” You’re probably right. But, this blog post is about how to not be Southwest.
Help your team and your leadership see why and how to not be Southwest. It is undoubtedly a fine art, but I am certain we can do better. The people sleeping on the floors of the airport deserve better.
