How to Move Fast and (not) Break Things

Most of the time I would like to slow down OS and app development. As someone who uses a great deal of software both for pay and for play, the endless updates have become a huge drain of both time (interruption) and money (paid upgrades). A yearning for a return to shrinkwrap software without bugs and with annual updates so to speak.

Two organisations changed the software world to perpetual beta, Google with everything in beta all the time and Facebook with its motto “Move Fast and Break Things”.

The main problem with this vision of a world non-buggy shink-wrapped software is it didn’t really exist even then. What happened was that one learned to live with the bugs in any given shipped version of the software. Once one had learned the voodoo around making the non-linear editor work with one’s video card without crashing on boot, and how to make the external tape deck respond to serial commands, one did exactly that and never varied.

The power here is that since the OS would stay static for two years and the NLE would only be updated when you wanted to update it (not often hopefully, although features were added fast enough then that a new update often brought important new functionality), by carefully following ritual you would be able to work with the NLE in a reliable way (not in the case of Adobe Premiere though).

So if there is no world of stable software to which to return, what is an end user to do? The same as we ever did.

First – stop using the latest OS. Second – don’t install new versions of your programs unless you absolutely need the new functionality or have time to play. Let everyone else run into the bugs. With all your free time, create.

Developers though have different responsibilities than end users. Our main task is to move our software forward, both for technical (improve the software) and marketing reasons (show movement, keep users engaged). Glyph Lefkowitz points out the reason Move Fast and Break Things doesn’t work is that it leaves out the important part.

The motto has an implicit preamble, “Once you have done the work to make broken things safe enough, then you should move fast and break things”.

So start by building automated testing, live monitoring and versioned deployment. If you do this:

1. you’ll catch obvious bugs early pre-release
2. you’ll catch live bugs very quickly
3. you’ll be able to go back to the stable version if the live bugs are too much for a hot fix

Before shipping quickly, developers should ask themselves two questions:

1. It is broken in a way you already understand. If this is the problem, then you should not make the change, because you know it’s not ready. If you already know it’s broken, then the change simply isn’t done. Finish the work, and ship it to users when it’s finished.
2. It is risky in a way that you don’t have a way to defend against. As far as you know, the change works, but there’s a risk embedded in it that you don’t have any safety tools to deal with. If this is the issue, then what you should do is pause working on this change, and build the safety first.

But if you have fixed the bugs you know about and have built safety systems shipping fast is the only way to improve your software efficiently:

1. No matter how much code review, automated testing, and monitoring you have some bugs can only be found by users interacting with your software.
2. No bugs can be found merely by slowing down and putting the deploy off another day.

Once you have made the process of releasing software to users sufficiently safe that the potential damage of any given deployment can be reliably limited, it is always best to release your changes to users as quickly as possible.

These arguments are slightly disingenuous. Complex software could certainly benefit from two weeks of beta release to specific test groups, free or paid. A wide release just means more people experience more bugs.

Still Lefkowitz has convinced me to ship faster. We have safety systems and we’ll improve them.

That’s what I will do as a developer. As an end user though I’ll follow a different path. I’ll keep using an OS which is two or more versions behind release and I won’t use the latest versions of my media programs. I can already here the wailing about security from the brainwashed mob along with the gnashing teeth of those whose business it is to keep them scared. To those I will say – I will keep my web browsers up to date as they work on the front lines on the public web.

Alec Kinnear

Alec has been helping businesses succeed online since 2000. Alec is an SEM expert with a background in advertising, as a former Head of Television for Grey Moscow and Senior Television Producer for Bates, Saatchi and Saatchi Russia.