Move fast, break less

One of Facebooks’s mottos is “move fast and break things”. Being Facebook allows you to have multiple Mottos (remember “What would you do if you weren’t afraid?”). And being Facebook allows you to break things without losing all of your clients. But beware of drinking to Kool-aid of “business advice” from companies 1,000,000 times bigger than yours.

It has been said that “enterprise is slow not because it is stupid, enterprise is slow because it has paying customers”, Google, Facebook and its likes changed the paradigm because their main product was no longer their product, but their customers. Weirdly enough this is what allows them to continuously break their products (oh the humanity!).

When you are a small startup, whatever you do your product is going to be your product. And moving fast is your advantage over the established players. Fast is your single advantage.

As soon as the behemoths (either enterprise players in you target market or Silicon Valley giants suchs as Google) can be persuaded that what ever disruption you bring to that market is worth the while, they can align dozens if not hundreds of engineers, and don’t bet on them being stupid (anyone who bets his business on his competitors being stupid, incompetent or both, well is probably quite stupid and incompetent).

So moving fast is your best bet; Fast enough to capture a market you can defend when the others start accelerating. Fast enough to be able to raise enough money to keep going fast. But moving fast usually also translates into amassing technical debt. Its hard to have great unit testing coverage, while moving fast, so it does tend to break things, and not in the good way. And small structures have a harder time to negate the effects of technical debt than more “mature” organizations, you can’t “just put a dozen more people in QA”. Weirdly enough, people have higher standards regarding your service promising disruption of whatever, as compared to your old telco or cable operator. Going fast is not about going Berserk. Its about getting the method and the tooling right so breakage is minimized and manageable.

Slow down to go fast

Also remember that this “go fast and break things” motto goes against some other ideas, that have proven at least as valuable .. and “slow down to go fast” is one of them.

You need to choose well what you are willing to have broken from time to time, and what might make you crush and burn. Some bumps on the road can be fatal if you hit them at full speed (Security !).

The highest speed is 0

I love the highway metaphor on this: if you gradually increase the speed limit on the motorway (imagining that there will always be people to drive at the maximum allowed speed) the overall speed will gradually increase, until a tipping point where it will become zero. It will become zero because at a point in time there will systematically be accidents all the time blocking all traffic.

This is true even if we imagine “different lanes”. At a point in time accidents on the “fast lanes” will be so violent they will impact “slow lanes” too. The optimal speed in which you create and deploy new features should not be “the fastest you could possibly go” but the fastest you can safely go. And safety here does not mean having no accidents at all, just trying to be sure they are not going to make you crash and burn. That you don’t have a big “get out of business button” somewhere.

Remember how many people there are at Facebook to handle the bumps. How much procedures they have to handle crisis situations. And also remember the other side of this adage “on a stable infrastructure”.

You need architecture and infrastructure to go fast

This is where smart software architecture also comes into place. Decoupling to services and identifying those elements that evolve at a much faster pace than the others (because they do not impact security, because they have partial failure modes that permit them to deliver value even when there are problems..).

This is where services like Platform.sh offer incredible value. Platform.sh allows you to move fast while breaking very little. To churn out new features daily while ensuring not only the global quality of your service .. but also that there is no downtime, remember these days your clients expect you to be always up; Even if your startup is just 3 weeks old (twitter used to be down for hours on end… and no one would complain…).

Platform.sh not only gives you a fully managed and automated stack, it allows you to have your own architecture on top of it. Unlike other services you get a PaaS where you can coherently manage your whole infrastructure whether its a monolithic application, or a micro-service oriented architecture.

And because it also integrates seamlessly with the rest of you tooling, like Bitbucket of Github.. your CI systems, your code review system going for continuous deployment does not mean you are “hacking production”. On the contrary what you have is a fully traceable fully auditable infrastructure that can evolve with your needs.

Not invented here Infrastructure

Investing now, when your company is so young, in the DevOps staff, in the sysadmins, in the complex machinery that is needed in order to have all the Continuous Integration and Continuous Delivery systems to ensure high availability… well is not investing in your product. You won’t be moving fast if half your time is spent on generic stuff everyone else is doing. Put money in developers that do features not sysadmins that say “no deployments on Friday afternoon”.

Friday is a good day for deployments.

Because Platform.sh gives you an a couple of interesting guarantees, and one is that deployments never fail. When you deploy a new feature instead of modifying things on your existing production cluster, we simply create a brand new one; We can #ze the incoming traffic while all this is happening, so we can insure your data stays in a consistent state (there won’t be any lost transactions). If everything went fine, we will start sending traffic to the newly created cluster and later destroy the previous cluster; If something went sideways, we simply do nothing; This means that there is zero downtime for deployments.

Continuous Everything is about confidence

What these features allow for is a true form of continuous development and deployment; The project manager describes a feature. Developers create a code branch for that feature (we automatically create a full clone of production for each branch), when the feature is complete a project manager or QA can now validate the feature is what was wanted. They test it in total isolation. This feature is the only difference with production. They can test it with the real data. So they can be totally confident it is what they wanted. To put it into production a developer simply merges the change with the master environment. He can do so with confidence because deployments never break production. Time to start working on the next feature now; Deploying 20 times a day becomes a normal reality; Not something you need to be a huge Silicon Valley startup with armies of engineers to do. Any user of Platform.sh can do this. This is how you can move fast and not break things.

How Platform.sh helps you go fast

With Platform.sh you can do true Scrum style development where you integrate into your “definition of done”, “validated feature” but also Scrum-Ban or pure Kanban style of continuous delivery. Only developing, testing and deploying features in total isolation allow for this; and currently nothing we know of but Platform.sh supports this.

Downtime sucks

Downtime is very often directly linked to broken deployments and poorly tested code. Because we eliminate those we allow you to deploy with confidence. You can iterate fast, react to the market. Test new features. Change. All without downtime. Because downtime sucks.

Go fast and stay in the race

Platform.sh kills development-staging-production and replaces it with something much better; A world where fear of change disappears. Where your teams can realize their true potential Platform.sh allows you to be bolder. To move fast, and yet, not break things.

And the Enterprise offering of Platform.sh is not only a highly available system, it is also a very scalable system, so if moving fast allows you to have early traction, well you know that you won’t be failing by succeeding. We can just make your clusters bigger, dynamically, without downtime, we can add more redundancy, so when customers are there to give you money, you are there to take it. So its not about doing a single sprint. You can go fast and keep going. Like a marathon runner.

So you can continue on innovating, moving fast.