Before getting into writing bug-free code, let’s start with a story. Late one night, I got a message from the CTO to swing by his office.
CTO: “So I heard your project’s timeline is slipping. Is that true?”
Me: “Uh…where did you hear that from? We’re on track.”
CTO: “Chad¹ said there’s a delay in your timelines because you decided to do a major refactor.”
Me: “I don’t think that’s true. We finished our MVP (Minimum Viable Product) early and received new business requirements, so we decided to do a refactor before we start the next milestone.”
A week later, I had a similar conversation with another executive.
Executive: “Hey, I heard things aren’t going so well with your project.”
Me: “Where’d you hear that from? I’m surprised — I thought everything was on track.”
Executive: “Hm. Chad told me that one night when he was staying late at work, he overheard some of your engineers complaining about how things are always broken and that they’re always fixing bugs and debugging issues. He kept asking, ‘why does our software have bugs?’ and ‘why is everything broken?’ and is confused why the status tracker shows everything as on track.”
Chad was a project manager that had spent his entire career at large banks in back-office roles. While he was familiar with how banks developed software — typically by throwing business requirements over the fence and waiting for engineers to code — he was unfamiliar with how tech companies operated. He didn’t realize that bugs are expected in software development and not a sign that the sky is falling. Similarly, refactoring did not mean someone messed up.
Having almost exclusively worked at tech companies myself, I had never considered that these terms might be misconstrued by coworkers. In search of a solution to work effectively with Chad, I recalled a lesson from my early career days about “framing.” The idea is that the same concept can be said in different ways to capture different audiences.
At our next team meeting, I announced a new set of terms to use when discussing our work with cross-functional partners outside of our team. I explained that since we work with cross-functional partners of all backgrounds, we need to ensure that we say things in ways that won’t get misinterpreted. Here are a few of them:
- Refactor => Implementation Enhancement
- Bugs => Edge cases not originally identified in the business or product spec
- Debugging => Investigating or researching
The same concept can be said in different ways to capture different audiences.
Almost immediately, confusion around our project status and timelines dissolved. The project managers were happy to hear that we were doing “implementation upgrades”, and one of them even commented, “I really like how you guys are always proactively improving our software. Thanks for always pushing the envelope.”
If you have spent your entire career in Silicon Valley tech companies, you may have rolled your eyes at the above story. However, the world is a diverse place, and there are lots of people with very different work experiences. (And yes, the above is based on a true story.)
As the world becomes more interconnected, there’s a greater chance we will work with people from vastly different backgrounds. Having spent most of my career in Silicon Valley tech companies, I was not used to people who had limited exposure to the tech company way of software development. It forced me to go back to first principles to rederive the concepts and assumptions when I explained them to people from other backgrounds.
While the above examples may seem extreme for engineers in the tech industry, framing is a powerful tool that can be applied to day-to-day scenarios. Ultimately, it comes down to empathy. There’s a Chinese idiom, “隔行如隔山”, which loosely translates to “different trades; different world.” In a previous article, I argued that instead of the golden rule, we should “treat others the way they want to be treated.” Similarly, it is important to present content in a way that your audience can interpret the same way you intend it.
Different Trades; Different World.
For example, at Airbnb, there has been a big push to migrate to Service-Oriented Architecture (SOA) from our monolithic architecture. Product managers typically consider it a tax and prefer to prioritize new feature development. However, if we constantly delay SOA migrations, we will eventually grind to a halt — unable to develop any additional features.
Instead of arguing why we should do an SOA migration vs. develop a new feature, I would frame the SOA migration as an investment in a context that is more relevant for PMs. For example, “doing this migration will reduce our page load time by 500 milliseconds, which will drastically improve user experience”, or “making this technical architecture update will reduce our development time by half for this set of features in our backlog.”
That said, if you take framing too far you may run into trouble as well. I have certainly seen cases where people take it too far, losing the trust of their audience in the process. In my next article, I will discuss how to stay honest when framing.
As for how to write bug-free code? Just don’t call them bugs.
[1] Names and identifying details have been changed to protect the privacy of certain individuals
If you enjoyed this article, check out Part 2: Staying Honest when Framing.
For more musings on tech culture, organization building, and management, follow me on Twitter @kenk616.
