This Guest Post was authored by Rob Zuber, CTO of CircleCI. CircleCI is the world’s largest continuous integration and continuous delivery (CI/CD) platform. Below, Rob examines best practices for growing a dev team from the very beginning. Part two covers 11 to 20 engineers.
The article below is an excerpt from The Startup Founders’ Guide to Software Delivery from CircleCI, available in full here.
Software delivery on a team of 2 people is vastly different from software delivery on a team of 200. Over the growth of a startup, processes and tool choices will evolve naturally – but either optimizing too early or letting them evolve without a picture of where you’re headed can cost you in time and agility later. That’s why I want to talk to you about how to evolve your delivery process with purpose.
The optimal approach to software delivery is tied to your software architecture, which, as we know from Conway’s Law, is in turn related to your organizational structure. Throughout this article, I’ll be offering insights on how each of these factors play a role in setting you up for either turbo-charged growth or mounting roadblocks as you scale, depending on the decisions you make at key inflection points.
Founding Stage: 1-10 Engineers
This is my favorite stage of company development. You’re excited. You’ve got an idea. And the last thing you want to work on is tooling. At a certain point, you’re deploying your 20th change to your initial environment by hand. You might be thinking “this can’t be the right way to do this.” And you’d be right. Even though you technically can operate like this, this is the time to put CI and CD in place. At this early point in a company, you might not even be in the right business, but rapid delivery and confidence in your releases will be instrumental in helping you get there.
This exploratory phase demands simplicity. Coordination costs are low at this size so use that to your advantage: a single team, a monolithic codebase, a basic (automated) deploy.
You don’t want to stop and ask your cofounder: “Hey, remind me the Capistrano command?” or “Did I just push on top of your push?”
You don’t want your laptop to be the “build laptop” where when someone wants to push code, they have to come to you.
With the click of a button, you could have CI/CD. Don’t make it harder for yourself. CircleCI has a free plan. Use it.
Just this one single move, even if you don’t “need” it right now (and I’m going to try to convince you that you do), this one move will set you up to be leagues ahead later down the road. When things get real and you’ve got a security problem that’s blindsided you, or you actually have customers and are tackling issues of scale, you can just ship a fix.
And that is way better than “Rob’s at lunch, we can’t deploy.”
Early-Stage Dev Team Do’s…
- Put CI/CD in place now. Your application is changing a lot and you want to learn as fast as you can. Don’t burn time trying to remember how to safely deploy. When your systems do start to necessitate more complex (and I will explain later why you should defer complexity as long as you can) you will have the practices and tooling in place to handle complex systems.
- Keep it simple. It’s so easy to have CI and CD in place. Get Google Analytics and set up CircleCI. At this stage, that could be all you need. But not having them is a huge problem. By not having these basic tools, you give your competitors a massive edge. Building a company is all about execution; acquire the tools you need to execute reliably, and put off the rest.
- Create placeholder implementations. This basically means to defer complexity, but jumpstart processes that support complex parts of an engineering org early). Traceability is a great example of a process that’s relatively easy to set up in a monolith, but much harder to put in once your application has scaled to include services. Why bother? Having traceability drives certain behaviors and decisions. Because there is even a simple implementation, you’ll think about traceability in everything you build. Putting these practices in place early will actually change the way you code. You will end up with fewer asynchronous handoffs in your codebase, or you’ll design them in a way that you’ll be more likely to understand later.
- Think, don’t act. Knowing what your future constraints are or might be doesn’t mean you have to build to them. Building is expensive, thinking is not. Think through your scaling roadmap before you make decisions so you can make conscious tradeoffs about what you’re deferring to the future.
- Prioritize operability from the beginning. The first developer in a startup should already take responsibility for thinking about the operation of the software. It should be apparent in the first line of code. For example, the effort to select a logging library that can redirect output to a central system is negligible. While you’re at it, structure your logging and either remove or structure the log points you were using to debug as you built.
…and Don’ts
- Copy the big players. You are not solving the same problems as Netflix, Google, or Facebook. The advancements they are focused on are unlikely to even translate into your context, let alone be useful as a direct copy. Keep it as simple and flexible as possible. Hopefully you’ll get there someday, but today is not that day.
Read the complete The Startup Founders’ Guide to Software Delivery from CircleCI.