Software engineering should be fun – really, really fun.  It is a totally engaging activity, that allows us to express our individuality, work together with others, and create something that people find useful and at the same time emotionally up-lifting.  Software is art.  Art is fun.

When software ceases to be fun, it means we are doing something wrong – something we should correct as quickly as possible.  Because, aside from being a good thing in and of itself, fun leads to faster delivery of higher quality software.  Lack of fun, well, leads to the opposite.

One of the big ways we get in our own way in this regard is by creating Cargo Cults.  Cargo Cults are a major fun-reducer, and they take a great deal more work to avoid than one might think.

A cargo cult happens when otherwise well-intentioned people choose to use some working method for no other reason than because someone else has told them that it is a good thing.  The way to avoid participating in a cargo cult is to really understand the underlying principles involved, starting with the problem that is being addressed,   In fact, many cargo cults start without even bothering with addressing a problem – the solution becomes so popular that people forget that one day in the distant past it was proposed as a solution to a particular problem.

Two of the biggest buzzwords in the industry in the last year (or two), DevOps and Microservices are ripe to be used as fun-sapping cargo cults.  Unexpectedly, they’re both solutions to the exact same problem.

So – say you read in your favorite development blog that DevOps and Microservices are Good Things(tm) and that all the cool kids are doing them.  How do we keep that from becoming a cargo cult and thus sapping the fun out of software, ultimately causing quality, morale, and throughput problems throughout your organization?

Step 1:  Make sure you understand clearly, for yourself, what problem or set of problems these solutions are useful to address.

Understanding clearly means being able to articulate it easily in a sentence or two.  Simplicity betrays understanding.  If you can’t express the problems simply – you don’t understand them well enough.

As I said earlier, in the case of DevOps and Microservices – we have two sides of the same solution-coin.  The problem that we are seeking to solve is how we scale while keeping an aligned delivery team focused on end-user value.  Every software delivery team starts out delivering what I like to call “Devopsy-Microservices”.  It’s what’s natural when you have a small group of people creating software – you focus on a small set of features, delivering them as a group out to an end user.  Everyone on the team has their head around the entire stack, and probably everyone can move the entire stack to production with a few keystrokes.

As we scale our delivery teams, there are two big mistakes that are super tempting to make, and that always seem like the intuitively right thing to do.

The first mistake is the perceived economy of scale of grouping together like skills.  The unintended consequence here, is that the skills based teams, while maybe slightly more efficient at their particular task, optimize for their skill specific task at the expense of the value delivered to the end user.

The second mistake (which is a result of the first) is that we layer our software much like we layer our teams – and thus any single feature necessarily requires multiple teams to deliver.  This obviously dilutes focus.

Step 2:  Make sure you understand clearly, for yourself, if you even HAVE the problem(s) that you believe the solutions solve.

If you are a two person development shop, and you write code, and you have access to make changes to production, how you think about DevOps and Microservices will be completely different from someone who has already scaled the wrong way.

You can simply choose to scale the right way as you add people…..if you add people.

Step 3:  Make sure you understand clearly, for yourself, what the underlying principles are that are in play and how the solution is addressing them.

There are a lot of complicated, counterintuitive effects related to how you might scale a software delivery team.  The very relationship between Microservices and DevOps is a prime example of this.  As I said earlier – they’re really solving the same problem – keeping a delivery team aligned and focused on end-user value.

The reason that they are both solutions to this is due to a counterintuitive law of software development called Conway’s Law – which, paraphrased, basically says that software mirrors the organization that creates it and vice versa.  DevOps seeks to align the organization and Microservices seeks to align the software. And again, both of these assume you’ve made some bad decisions already as you’ve scaled, and have to wind them back.

Step 4:  Take the long view.  And be persistent.

Finding the underlying principles and then steadily applying them is not a microwave thing – it’s a crockpot thing.  You won’t notice any instantaneous, dramatic, short-term effects.  What will happen is that as you make good choices along these lines, you’re software and delivery flow will slowly but markedly improve.

And this is definitely the case in Devopsy-Microservices.  If you’re way down the path in a (so-called) monolithic environment, with functionally siloed teams, it will take a lot of hard, diligent work to get back on to a good path.  If you are a small startup – and you’re just “trying to get product out the door” – I’d urge you to set yourself up for future success with the long, arduous work of scaling well rather than piling hack upon hack.

As with any accomplishment – the real way to win is to use time as your ally, steadily adding value rather than looking for the short-cut-promising Cargo Cult.  The Cargo Cult will tell you not to think about pesky, complicated things like underlying principles, but to just go ahead, click your heals together three times while throwing the magic beans in the ground before riding off into the sunset on your rainbow colored unicorn.

I say – let’s forget the unicorns and do the hard work of writing some incredible software!

-kyle