The Worst Thing You Could Learn From Your CTO and Why It’s the Right Thing To Do
Stop thinking about your solutions as exclusively this option or that alternative.
I was stunned by the comment line I saw in the code.
A rush of good cheer came to me. This code was an example of the culture we were building — to ship quickly and constantly clean up after ourselves. In this case, I was the CTO.
What’s wrong with this code?
My colleague and I would claim that this code works and solves the problem at hand. So what’s wrong?
There are many sins in programming. For example, global variables, poor naming, and leaky abstractions make code an unmaintainable mess. In this case, the sin is hardcoding — using a specific value rather than an abstraction. Consequently, this code block will run only for the user identified as 1234.
This code solves the problem for user 1234. But, unfortunately, it does not solve that problem for other users, who might be in the same predicament.
What is the right design?
There isn’t a single correct solution. There are, however, solutions that are easier to read, easier to maintain, and easier to change over time.
A more flexible, maintainable design would put the specific values somewhere outside the code.
We could refactor this design to pull these values out over a few different steps:
- Check against a list of values rather than a single value.
- Pull the values out into a configuration file.
- Pull the values out into an environment variable.
- Retrieve the values from a database.
- Encapsulate the logic into the domain model, avoiding id values altogether.
Each solution leads to more flexibility in the code and opens the functionality to more users and more situations.
Why is a hardcode the right thing to do?
We were solving a production issue. After triaging the problem, finding the affected code, and creating a solution, we could roll it out with the hardcode within 30 minutes. The more robust, maintainable solutions would have taken several more hours of development and testing.
We stopped the bleeding by fixing the production issue. We took on technical debt using a hardcode to make the fix quickly.
We made an engineering trade-off between time to market and code quality.
How can you have both?
As soon as we deployed the fix, we went back to the code to pay down the debt. We didn’t let the debt linger, accumulating interest, fees, and penalties. We did not allow the debt to slow us down.
As I get older, I realize that upgrading my thinking from OR towards AND makes sense. My head hurts trying to hold two conflicting ideas at once. Yet, embracing the tension leads to creative opportunities.
Stop thinking about a solution as exclusively this or that. Instead, start looking for ways to incorporate this and that.
In this case, we rolled out a solution quickly and followed it with a robust implementation.
👏🏻 Give me a clap and “follow” if you enjoyed this article.
📋 About Milo
I am a tech executive, writer, speaker, entrepreneur, and inventor. I’ve been developing software since 1995 and developing teams for over a decade. 🚀
I write articles about software, engineering, management, and leadership.
You can also follow me on Twitter. 🐦
