The Software Triforce, Part 1: Setting a Courageous Goal

4 minute read Jonathan Ming on

In nearly every installation of The Legend of Zelda, there is a resonating theme among the characters: the mystical power of the Triforce. Wisdom, Courage, and Power, the three forces that comprise the Triforce, are each quite powerful, but their strength is greatest when they are used together. I’ve found that these three forces make a huge impact, not only in the world of Hyrule, but also in the world of software development. So I’ll be writing a series of posts about each one in turn, focusing on the pursuit of stability in your software projects.

Everyone wants to claim that their software solution is entirely stable. But maybe you can’t honestly say that about your project. You’d be in good company; it’s all too common for developers to get stuck working on—or worse, air-dropped into—a project with a long and twisted history that makes it notoriously unstable.

I was in that boat a few months ago; if you’re in it now, then if you’re anything like I was, you’re feeling a little overwhelmed. But there’s good news; I made it out and you can too! I’m writing from the other side to tell you the guidelines that were most instrumental in helping my team achieve our stability goals: to have a clear vision, to take it one step at a time, and to employ tried-and-true solutions.

Hopefully these guidelines will equip you as they did me, so that you no longer feel overwhelmed, and so you can pursue software stability with courage. In this post, I’ll be talking about the effects having a clear vision had on my software stability efforts.

Have a Clear Vision

Software instability usually doesn’t appear overnight. It slowly creeps into your application, infecting more and more, until it feels like there’s an unclimbable mountain of work between you and stability. When you find yourself at the foot of that mountain, it can be super discouraging.

Several months ago, my team was tasked with taking an existing app (an online donation platform) and making it “stable.” The project had all kinds of problems that caused instability: messy code from a rushed initial development phase, undocumented functions left behind from a former employee, and integrations with external services that had their own unsolved distributed system problems, to name a few. We hardly knew where to start, so I started listing all our woes to one of my coworkers. As I vented (and as my coworker graciously listened), I started to notice how some of the things I thought were huge obstacles didn’t sound like as big of a deal when I said them out loud. This made me stop, take a mental step back, and start to think:


Is any of this even important for the project?


Of course the answer was “yes,” but starting with this question, of what’s important, was a huge shift away from asking which of my problems was the most stressful. When you focus on thinking about which of your stability problems is the worst, it’s all too easy to get lost in a sea of frustrations, annoying bugs, finger-pointing, etc., all of which are harmful, not helpful. But when you focus on what’s most important for your project—on what really matters—that’s what will show you where to start. Once you know what’s important, you can just start with the stability issues that impact the most important part(s) of your project, and that’s that.

This exercise of revisiting the project’s priorities turned out to be crucial for several reasons, but the best thing about it was that it was encouraging. When we reminded ourselves of the project’s purpose and requirements, we realized that there was a relatively clear path to the top of that imposing mountain of stability work.

Having a clear vision of our purpose allowed us to prioritize effectively. By prioritizing, we turned the overwhelming wish list into a set of concrete requirements. And once we had that, we were finally able to accurately define what “stability” should mean for our project. For our donation platform, we decided that our stability goal was:


“Not a single donation is lost, and there are no unhandled errors except those caused by bad user input or service outage from one of our integrations.”


Having this goal in sight boosted our courage—no longer did we feel incapable; instead we had a clear path forward.

The very act of setting this goal was a courageous step for us. Instead of waffling about from task to task, or procrastinating because we weren’t sure how to start, we drew a line in the sand. Our consideration of the project’s priorities ensured that we knew both what to do and what not to do as we sought stability.

We had set ourselves a clear and courageous goal, and in doing so, we found the inspiration to achieve it.

Have any questions or comments? Have any concerns? Feel free to reach out to us!

Interested in writing secure software? We’re hiring!

—————