Delivering Software at Mimecast- like Facebook?

Co-authored with Liam Bennett- Software Engineer, Mimecast. You can find Liam on twitter @liamjbennett and

For those of you who haven’t read Facebook’s S1- the notice that they’re going to become a publicly traded company – there was an incredibly important couple of paragraphs about how they deliver the service to their 800+ million active users and nearly $4 billion in revenue. They called it the “Hacker Way.”

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it — often in the face of people who say it’s impossible or who are content with the status quo.

Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations, rather than trying to get everything right all at once. To support this, we have built a testing framework that, at any given time, can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to constantly keep shipping.

And to some, it might seem shocking  for us – a highly available, security focused SaaS company – to compare ourselves to a consumer service like Facebook.  But what all the companies that deliver internet services to customers at scale have realised is: if you don’t ship and continuously improve, you could fail.

Our CTO, Neil Murray, talked about this very problem with the BBC recently:

 “We’re an email company, but our technological problem isn’t email, really. It’s the production of technology.

Traditionally, the way people have built software has been fairly linear. You design it, you build it, you ship it.

But in the cloud space, and certainly in the email space, the evolution of the code is so rapid that our biggest problem is getting new features out in days, not weeks or months or years.”

And that’s where Facebook comes in. We have to continuously ship, or deliver, our software which creates our service – methodology called Continuous Delivery.

Much like the Agile practices of previous years, it is a process that is done well by some, to extremes by a few and misunderstood by many. I mean, if you ship something early and often, couldn’t there be bugs or mistakes in there?

As it turns out, it’s exactly the opposite result.

The bigger the release, the more complexity you have to deal with and the more risk you introduce. If you deploy one line of code at a time, you’ll soon find out whether that line of code has a problem with it. Even better, you can perform automated tests on that line of code to make sure it doesn’t break anything else.

Reducing risks in deploying software is brilliant, but that doesn’t solve the velocity problem Neil was talking about.  Removing the barriers to deploy and test code increases developers ability to do this, thus drastically improving their productivity and velocity.

Releasing early and often also means you don’t suffer the same roadblocks and dependencies “I can’t do my coding until version xyz is in production.”

Why does this matter? Because it enables us to deliver a better service to our customers, with more features, better reliability and be more responsive to customer needs.

In our next post, we’re going to talk about how we actually achieve Continuous Delivery.

Photo CC via Laurence Vagner and Peter Zoon on Flickr


  • email archiving solution

    Great post! I really like your opinions. Some great pointers in here. Thank you!

    • Justin Pirie

      Thanks! What did you like best?