The Hill You Must Die On
You get excited about the solution. You see the world in sunshine and rainbows. But lurking beneath is the most evil villain in all software.
You're presented with a problem and you get excited about the solution.
The idea phase is always exciting. The possibilities are (truly) endless. Envisioning the upside takes hold. You see the world in sunshine and rainbows.
But lurking beneath is the most evil villain in all software.
He spirals your system into chaos. Instead of building features, you're squashing bugs. He wakes you up in the middle of the night with an on-call page. He slows your product velocity to 0.
No, it's not your scrum master.
The villain is:
Complexity.
Throughout your software dev career, you will always fight complexity. And you must fight and die on that hill.
It's your job to grow and maintain the systems you build. Whether you want it or not, you have skin in the game.
Luckily, there are tactics to battle complexity.
You are not obligated to build every idea.
As an engineer, your nature is to obsess over solutions. And indeed, you are hired to build solutions.
But, the features you DO NOT add have more impact than the features you add.
The simplest code to maintain is no code at all.
I know, as a software dev in a startup, you are hired to write, build, and maintain software.
But you are not a code monkey. You are a problem solver. An inventor. An architect.
Challenge yourself to see the bigger picture and make the best decision for the business.
This may mean saying "no" to fun projects.
Such as: Yes, it would be cool to integrate Kafka. Or, you can read jobs off an existing database table.
So with every solution, ask yourself: Is this the best for me or for the team, company, business, and users?
Custom software isn't always the answer.
Each time you add a new feature, it takes a life of its own. A life you must tend to.
You don't have to build it:
Can you buy it? Pay for a SaaS or API?
Can you outsource it?
Does an open source project solve it?
Would a recurring calendar event reminding a human to take action solve it?
Can you build a simple UI to empower business users, such as with Retool.com or Airplane.dev?
Can you write a quick bash script attached to a cronjob?
Your job is to focus on the core value of your product. What about your product is unique to the business? What differentiates your product from others?
Roll your own user authentication? (Almost certainly no. Outsource to Auth0, Firebase, Supabase).
Roll your own on-call alerting? (Nope. Use PagerDuty or OpsGenie.)
Need to ingest a large CSV file? (Add a bare-bones admin UI and empower a business user do it.)
I'm 99% certain your company's unique value isn't user auth, on-call duty, or ingesting CSVs. It's something else.
Focus on nurturing the "else" with your custom software. Outsource the rest.
Focus on the problem, not the solution.
It's human nature to jump to solutions. That includes people who are not engineers - managers, executives, customers, and the barista in the coffeeshop next door.
Take them as suggestions, but do not commit to any yet.
Instead, ask questions. Lots of them. You must often work backwards from suggested solutions. Find time with an SME (subject matter expert) if you're not an expert in the domain yet.
By asking questions about the problem, you unveil the bigger picture. Once you see the big picture, you see other avenues, like zooming out on a map.
Asking why is helpful. (Try the Toyota 5 Whys technique).
You will be amazed at all the other options you discover when asking questions to define a problem.
Strive to find the simplest solution that solves the problem AND brings value to the business.
Wrap Up
The above are a few techniques to battle back the #1 villain: Complexity. These tips are non-exhaustive. I could write a whole book on battling complexity, so expect more on the subject.
Counterintuitively:
Simplicity is hard. Complexity is easy.
It's easy to add new features, more database relations, more modules, more dependencies, more microservices, and more git repos.
But such a system is hard to maintain, refactor, and change. As a system grows, disparate parts become connected in surprising ways. A change to one part affects another - or many others.
As the old saying goes:
an ounce of prevention is worth a pound of cure
Prevent complexity and strive for simplicity from the beginning.
If you liked this post, subscribe for future ones on how to thrive and survive in the tech startup world: