Code structure must scale as an organization grows. I’ve said before that Scaling is Performance decoupled from Load, and I think the analogous statement might be that scalable code decouples maintainability from team size.
At an early stage, we’re all just strapping things together with duct tape and working to get our ideas validated by our markets. The pressure on code at this stage is to be minimal and functional, and directions change, as does structure, with great frequency. You’re usually optimizing for a team of 1, maybe 2 at this point, who can know the length and breadth of the code base by rote.
Inevitably there will come a point where you’ve hired 2 more programmers, your customers are clammoring for new features, and you’re still saddled with a code base designed for 1. The next big release goes far beyond its deadline. Programmers complain about APIs. New bugs are cropping up left and right.
What makes code maintainable by a larger group? Standards and well-design interfaces. There are heavy-handed processes you can implement to make sure every line of code is linted, reviewed, etc, but in a startup (even a growing one) your focus should still be individually empowerment and speed to market.
But make sure at least the following are in place:
QA. You’re going to break a lot, do find a detail obsessed person who can tell it like it is.
Naming conventions. The first thing you need to do is get everyone speaking the same language. Semantics is the core of software, so encourage the arguments and negotiation to happen at this level.
Interface design. And I mean interfaces like as in API, not UI. Your senior players are going to have to get good at thinking through interfaces. This requires treating code as a product, and applying UX principles, and thinking about consumption of your APIs by other team members.
Explicit architectural goals. Its probably too soon to have an Architect dedicated role, but your team needs to be able to make sound decisions as they work, in accordance with a set of common principles and roles.
Code review. There’s a whole other post in my head on Scaling Process, but for this one suffice it to say that all of the above will require you to keep yourselves honest, and communicate your progress and standards, and code review is the best way to get it going.
Good luck. This is the fun part.
