Scaling Your Code Base – Is your Startup Growth Stage Ready?
Your MVP works; there’s a market for your idea! Awesome, great job!
Before you start massively growing your customer base and making some serious money, think about your software. Is the code a jumbled mess? Will it ever make sense for the throngs of new devs you’re about to hire?
It’s okay if it doesn’t. It may actually be better that way.
Let me take you through some of the most common obstacles any Growth Stage Startup needs to overcome when scaling their code.
01.
6 Scale-up Code Necessities
In the Growth Stage, everything grows. Your user base, your revenue, your team, your code. The structure of ten thousand lines of code differs greatly from that of ten million.
Therefore, it’s best to look at your code while it’s still somewhat small and ensure it’ll handle growth.
The 5 necessary properties of any large codebase are:
Tests
Traceability
Observability.
Decoupling
Scalability
Tests
Their usefulness is twofold:
Tests explain how a specific part of the code should be used and what you should expect.
They prepare your codebase for future additions. Your dev team will have a higher level of confidence that the new addition did not, in fact, break all the other stuff.
What about code coverage?
It’s very nice and tempting to reach, say, 95% code coverage. It may also be unnecessary and expensive. Even at 95%, you can still miss a critical path. The goal is to identify and cover only what really matters. To find the “just right” balance between the costs and code stability.
As a rule of thumb, if you keep adding code, code coverage should stay the same. It’s important to watch the trends, not the absolute value.
Traceability
Whenever there’s a problem, you should want to know where and why it happened. Often, you need to trace the root cause through a chain of components. To do that, you need all those logs to be traceable.
It’s just more efficient.
Observability
Observability ties into traceability. To trace a problem, your components need to be observable. That means you need to be able to find out what they were doing, when they were doing it, and why. For that, you must log an appropriate amount of telemetry information (not too much nor too little).
Decoupling
The more dependencies and ties between your software’s components, the harder your testing, traceability, and observability become.
Decoupled components mean lower deployment risks. They make replacing old code easier on a smaller scale, give you more flexibility in picking the right technology, and make experimenting with new features much easier.
Scaling
If you can’t scale due to code issues, that’s bad.
It makes your investors unhappy.
Fortunately, there’s an easy solution. If your product has tests, the code is traceable and observable, and the components are decoupled to an acceptable level, your code will be inherently scalable.
Let me say that again. To be scalable, have tests and reach traceability, observability, and decoupling.
02.
Should you Ditch your MVP Code?
No.
“Your MVP code is too much of a mess. It can’t be scaled. Let’s ditch it and build something new from scratch,” you may have heard an expert say.
While that may be true 5% of the time, most “experts” simply don’t understand your old code.
And let’s be honest, NOBODY likes poking around in someone else’s old code. Greenfields are just so much more comfortable to build upon.
However, by building it from scratch, you risk building it differently, yet still wrong.
So, unless your MVP is built with discontinued technology, you should just work with what you have. Get your hands dirty, find what works, fix what doesn’t, line by line.
03.
Documentation and Knowledge Sharing
I am a big believer in having no other documentation than the code itself.
Let me explain.
Your code should be clear enough not to need any documentation. You should comment on any unclear and chaotic parts, explaining your intention and reasoning behind writing the code in such a way.
Feel free to make shortcuts, but be sure to know why you’re making them and what their tradeoffs are.
If I were to document something, it would be a simple guide on how to run the project.
Make a README.MD file in the project’s root directory containing instructions on what is needed to run it. Include all the places you’d need access to, a list of persons that can grant said access, an order of commands, and the CI/CD setup.
It’s no more than 20 lines long and saves you priceless hours of digging it all up by yourself. Especially if there’s a non-trivial process hidden somewhere in the MVP.
Any other type of documentation makes sense only if you KNOW somebody is actually going to read it regularly. Or if it’s required by law, a regulation, a certificate, etc.
Code Reviews as Knowledge Sharing
Code Reviews is a great knowledge-sharing platform. A developer builds something, their peer checks it, knowledge is shared, and opinions confront each other.
When the opinions differ, they clash. Afterward, the opinions either converge or one of them dies away. Either way, equilibrium is restored. It’s beautiful, really.
Meetups
Especially when your company is fully remote, quarterly in-person meetups are AMAZING at knowledge sharing. The team meets, and the developers mingle and discuss their problems and solutions.
And there’s a party, of course.
04.
Technical Debt is a Good Sign. Yes, Really!*
*Provided you know it exists. It means you didn’t overspend on your MVP.
If, on the other hand, the tech debt crept up on you unknowingly, that’s hell (and worth its own separate article 😉).
Think of your MVP as if it were a house. Unlike real houses, the MVP only has to look good on the outside and must prove it’s habitable. Nobody cares that the electrical wires inside are all over the place, uncovered and crisscrossing each other.
Your house is habitable = your MVP has found its product-market fit. You didn’t waste effort and financial resources polishing out all the details. You went straight into making sure people actually wanted your house.
All the polishing and cleaning up happens NOW, in the growth stage.
Balance Reducing Tech Debt with Developing New Features
It’s time to divide your time and resources.
The perfect ratio is 60% for new features, 20% for tech debt, and 20% for bug fixes.
Actually, that’s a lie.
The REAL perfect ratio is 80/10/10. Or 70/15/15. Or 90/10.
Or maybe the perfect ratio doesn’t even exist.
The point is that you’ll usually need to dedicate MORE time and effort to developing new features and LESS to reducing tech debt and bug fixes.
The actual ratio will depend on the state of your code and your priorities. It’ll vary.
05.
Set up your CI/CD pipeline
If you’ve been avoiding automated deployment up to now, you NEED to implement it in the growth stage of your startup.
Your codebase will blow up, and merging branches manually will quickly become a nightmare.
Your CI/CD pipeline should include at least these 5 things:
Automated tests
Code checks
App builds
Code Reviews
Infrastructure as a Code
Automated Tests
This point ties nicely into the tests I’ve already talked about. Your tests should run automatically in your CI/CD pipeline whenever a developer commits. Or, at least before merging. If there’s a problem, your team gets notified. Automatically and asynchronously.
Code Checks
Your CI/CD pipeline should also include various code checks. Lint and Formatter come to mind. The former runs a static check for some usual shortcomings, and the latter prevents wars about “{” belonging to the current line or the next.
App builds
The builds and deployments of your app (of any kind) should ideally run through your CI/CD pipeline.
You’ll ensure the build is always made in the same conditions, making troubleshooting much easier.
Manual builds and deployments are prone to error, and there aren’t many cases where they make sense (but they do exist). It also takes time. When it is automated, developers can focus their attention on something more useful.
Code Reviews
Code reviews can be automated as well. Turn them into a process that goes after the automated tests and code checks but before merging the code into the main branch. It’s an asynchronous process, provided you use the right tools.
Infrastructure as a Code
Don’t forget about your Cloud! Setting up your Cloud manually is yesterday’s news. You should have a CI/CD pipeline that can set up your Cloud environment from scratch, repeatedly, and predictably. It’s a massive time-saver, and it eliminates inefficiency.
06.
Get Your Tech Team Ready
Team scaling is its own beast altogether. So much so that the topic has warranted its own article. Go ahead and read it. It’s well worth the 5 minutes.
If you’d like a quick rundown right now, here are 5 pointers to help you out:
Switch to a Team Ownership mindset.
Turn your Rock Star developers into Dev Leads.
Find a good Development Partner and set up your cooperation.
Learn about asynchronous communication and master it. (This is important!)
Aim for as few fixed meetings as possible.
Get the right tools for the job (Jira, Asana, Trello, GitHub, etc.).
07.
Wrapping up
I hope that’s been as exhaustive as possible without delving into too much in-depth information for each subject.
Even then, it’s a lot. However, provided you’ve got great engineers, you probably already do most of the stuff I’ve listed.
To sum up, here’s a checklist of what your code needs when entering the Growth Stage:
Make sure you run tests, and you’re familiar with observability, traceability, and decoupling.
Double-check whether starting from scratch is a good idea. (It probably isn’t.)
Share knowledge of your code and think about the right type of documentation.
Work with your tech debt.
Set up a CI/CD pipeline.
Don’t forget about your team.
Good luck! And before you ditch your old code, send me a message. I’d hate all that hard work to go to waste.
Igor Liška — Co-Founder/Co-CEO
Let’s connect on LinkedIn →
I like building software just as much as I like building Legos.
Throughout the 14+ years of my engineering career, I’ve been a developer, an architect, a manager… Right now, I’m the Co-CEO of Panaxeo – the kind of company I’d always wanted to work for but couldn’t find any like it.
