lean

Go Lean: SysOps, DevOps, AppOps, NoOps

I’ve always been a big fan of tools and services that take complexity away from engineering teams and allow them to be lean and focus on what they do best: building their product and focusing on their own rocket science.

Back when I started to work with the Web, I remember us ordering an actual physical server, setting it up and loading it into our car to carry it to the data center. Fast forward a few years and you can do all of this within a few minutes without moving away from your desk. Especially working with infrastructure has changed a lot since AWS, Heroku, AppEngine, Parse and all the others appeared.

In one of my previous startups we thought “DevOps” would be the way to go, bridging the (cultural, among others) gap between developers and system administrators. Back then built it around AWS which still required work and expertise around the infrastructure.

Again fast forwarding a bit, this has even become simpler. Especially for early stage startups, where agility and the ability to move fast with limited resources and a laser-thin focus is more important than building proper scalable software, you can build stacks on tools that do virtually everything for you. Deploy your stuff to Heroku (or EngineYard, or …), make it “Continuous” with Codeship, CDN-ify it with Cloudflare, get your basic reporting done with Chartio, and so on. By building such a stack of tools you can nearly entirely avoid having to deal with the adminstration overhead you used to have when building software. In this post, Adron Hall of New Relic (who arguably knows a lot more about it than I do) talks about it calls it “AppOps” and “NoOps”. The former basically let’s you do your Ops work with applications that sit on top of your infrastructure and hide the nastiness, where the latter eliminates it almost completely.

There will be a time where you have to migrate away from these out-of-the-box tool stacks, be it for scalability reasons, or functionality, or cost, or other factors. But if you just need to get started and move fast early on, having “No Ops” sounds wonderful to me and the possibilities and tools are just getting better every day.

Building the Right Product with Hypothesis-Driven Development

In my previous post about Making Continuous Delivery work with Scrum and Sprints I wrote about how to shorten release cycles significantly by changing your process and adding in the obvious amount of test and release automation.

A comment challenged that by basically saying “Well, this might help you build your product right (and in shorter cycles), but building the right product is a whole different question. And maybe the more important one.” Hard to disagree.

I wanted to dig deeper. These days you can’t be wrong by starting in the vicinity of Lean Startup if you’re looking for how to build the right product efficiently. As an engineer I’m familiar with a lof X-driven development techniques but then I’ve came across one I haven’t about before: Hypothesis-Driven Development.

The basic idea is simple:

  • Instead of requirements, you formulate assumptions, or hypotheses
  • At the same time you define a measurable signal, that will tell you whether you were right or wrong in a reasonably short amount of time

This sounds like a great start to get to a structured approach to factor the question of the right product into your development.

But of course building the right product and building the product right aren’t mutually exclusive. Nor would I say one is more important over the other. They both are. Where hypothesis-driven development guides you to make sure you’re being intentional about your assumptions and the need to test them, good old fashioned engineering techniques like test-driven development and test automation make sure you’re implementing your hypotheses right. Without being able to successfully (bug-free and all) deliver an increment of your software that aims at testing an assumption, you’re not going to get the right answers either.

The article I stumbled upon was http://agile.dzone.com/articles/hypothesis-driven-development which also links to a great presentation about Replacing Requirements with Hypotheses.