Startup as you mean to go on

We’ve been setting up our little engineering team at Polystream HQ over this last week or so and even though we’re only four people, we’ve taken care to leverage all our experience and knowledge of “big teams” in the process.

As a startup you can easily set things up quickly, and you can just get dug in to start churning out code of course, but when you’re developing something where your actual IP is so closely linked with actual code you definitely want to hurry slowly and work in best practices right away.

From the start we’ve been thinking about the security and recovery of our work with machines and servers locked and encrypted and an off-site backup solution. There is nothing more frustrating, and potentially disastrous, as losing data because of a power fault, fire or even a break in. Making sure that your business, no matter how small, can be “restarted” with all the required assets and data at any point is therefore critical.

When the code itself is such a key part of what you do, what I call “good hygiene” is also something you want to establish from the start. I.e. coding standards and guidelines, code submission policy, and testing practices, etc.

We’re basing our coding guidelines on Google’s excellent style guide for C++ and we quickly got ourselves VisualAssist licenses to help navigate, refactor, and create code. Even with a small team this level of practices is crucial; you only get one realistic shot at establishing this sort of thing and once you have it will be much easier to scale and grow later.

Testing, in particular when you’ve got a lot of complicated algorithms in your code base, is another essential tool to keep your code at the highest level of cleanliness as you develop. It’s not easy; writing good tests is an art, but it is something which will save your bacon over and over again. We’re integrating the Google test framework which is an excellent, and pragmatic, test framework for C++ that “does exactly what it says on the tin”.

When it comes to communication and team management there’s always a risk that things get a bit “organic” when the team is very small and people sit next to each other. Good practices such as SCRUMs or 1-2-1’s might be considered an unnecessary luxury by some but for us this is as important to what we do as the code we write. In fact, I’d argue, that the smaller the team the more important these things are.

Our offices here in Guildford are situated on the river Wey and what we lack in meeting rooms we gain in picturesque surroundings. I’ve established our 1-2-1’s as a river side stroll. No meeting room beats that (except perhaps when it’s raining) and the team are already very happy with what we’ve started.


Follow Jarl on Twitter @psjarlo