Coding Is Like Cooking

Note: this was originally posted on Praqma’s blog

The life of a consultant has drawn me back, but perhaps surprisingly, this time it’s not a return to my one-person firm. Rather than reinvigorating Bache Consulting, I’ve decided to join Praqma, the Continuous Delivery and DevOps Company. I was pretty happy at Pagero. I’ve successfully run my own business before. Some of my friends think I’m crazy to leave a good job with a great team working with exciting technologies. Others think I’m crazy to not want to be my own boss again.

So why Praqma?

Code that gets used

Writing code is really good fun. Writing code that people actually use is even more fun. That’s one of the reasons I like setting up Continuous Delivery pipelines for a development organization. Anything you change gets used almost straight away, and you get feedback from people around you all the time. It’s a fantastic feeling when you implement something that means the whole development team can move forward more quickly, confident in the quality of what they’re producing.

The kind of work I’m talking about is setting up build and delivery pipelines using a CI tool like Jenkins or Go.CD. It’s automating all the installation steps needed for a new machine in a staging environment. It’s moving all the code into a modern DVCS like Git, and setting up automated processes to help keep the master branch in a working state.

In my experience, this kind of work gives you the opportunity to raise the productivity of so many other people, it can have far more impact than if you stayed in your cube hacking on a product by yourself.

Amplify your effect

Another activity I really enjoy is facilitating and teaching. Preferably that kind of teaching that you do from the back of the room, where your job is to set up situations where learning is inevitable. I’ve spent a lot of time over the years facilitating Coding Dojo meetings, and more recently I’ve started doing more Mob Programming with teams. My aim is usually to get people to experience effective development practices like Test-Driven Development (TDD), and understand the difference it makes.

Again, the focus is on raising the productivity of other people, this time through coaching and training. Actually, I’m not directly raising anyone’s skill level. What I’m trying to do is to activate people’s innate motivation to want to get better at their job, and showing them a way to do that. It goes hand in hand with making the technical environment they’re working in conducive to good practice by having good automation infrastructure. TDD makes a lot more sense when you have a CI system to run the tests, and information radiators that show you when the build is broken.

Raise your game

So I’ve just joined Praqma, which is a consultancy focused on Continuous Delivery and DevOps. I now have a host of colleagues who are also really skilled with this kind of technical coaching role I just talked about, and know how much fun it can be. We’re really good with tools like Jenkins, Docker, Artifactory and Git, we set up Continuous Delivery pipelines, and we coach developers in how to use them. What we’re finding though, is that once we’ve got all that set up, the next step usually involves improving the automated testing in the pipeline. We need to be there coaching developers in TDD, and getting automated system tests set up.

That’s where I’m hoping my joining Praqma will help us all to raise our game. Starting with the consulting work Praqma already does, which of course lays the foundations with Continuous Delivery, we can start doing more coaching in test automation. I have long experience of that, teaching TDD in particular. I have much less experience of some of the other things that Praqma does though. What I’m hoping is that by working together with the other consultants at Praqma, and collectively sharing our toolboxes, we can all have more fun and achieve more for our clients. I don’t mind working alone at a client, I’ve done it before, but having colleagues is so much better. We’re going to have a blast!

Join us

Praqma is expanding throughout Scandinavia right now, with offices in places like Copenhagen, Oslo and Stockholm already. I’m starting the office in Göteborg. If the kind of technical coach role I’ve just described appeals to you, I’d be delighted to tell you more, do send a mail, emily.bache@praqma.com, or a tweet, I’m @emilybache.

We’re not only looking for senior people with lots of experience, by the way. If you have the right attitude and willingness to learn, that can take you a long way. We’re looking for people to join Praqma at all our offices, please send your resume and a covering letter to jobs@praqma.com. Of course I’d be particularly pleased if you wanted to join me in Göteborg.

Note: This post first appeared on Pagero’s blog

One of the questions that Kent Beck asked when he was developing the eXtreme Programming development methodology, was what happens if we turn the dials up all the way to 10? Take a practice we know is good, and do more of it? Practices like Test-Driven Development and Pair Programming are what he came up with, starting from manual testing and code review.

In the same way, Continuous Delivery is what you get if you turn the dials to 10 on your annual release cycle. You get to the point that you are pushing out new code to users, many times a day.

“Shortening the release cycle like this has a lot of advantages, especially around risk and quality.”

LOWER RISK AND HIGHER QUALITY WITH SHORTER RELEASE CYCLES

Shortening the release cycle like this has a lot of advantages, especially around risk and quality. Basically, you’re decreasing the batch size, a well-known tenet of lean manufacturing. If each new release contains fewer changes, then you have fewer places to look when things go wrong, so finding bugs is easier. You also lower the risk that any individual batch has a defect in the first place. By having an engineering setup that allows you to make code changes at the drop of a hat and push them out to production easily, you facilitate getting fixes out quickly.

So the upshot is quality problems surface sporadically instead of all at once, and are more easily dealt with. It’s an attractive prospect for us, especially with the growth in traffic we’re experiencing. Every time we have a defect in production, it affects a proportion of our customers, and the number of customers is increasing all the time. If we had a small bug a year ago that affected one or two customers, today the same bug might affect tens or even hundreds.

FROM MONOLITH TO MICROSERVICES FOR GREATER FLEXIBILITY

At Pagero, historically we’ve been pushing out a new version of our product “Pagero Online”, about once a month. We’ve been able to sustain that since about 2007. So when we began looking at Continuous Delivery, about three years ago, we were starting from a fairly good position. We’ve experienced steady growth in transactions through our cloud platform since the start, and it was in early 2014 we started switching over our architecture from a clustered monolithic JEE instance, to distributed microservices (see my previous article).

We needed to do this, in order to scale out our system horizontally, and handle the increasing traffic. One of the other benefits of microservices though, is you can deploy services independently of one another, and if you do it right, you can deploy new code without stopping traffic to the site.

“One of the other benefits of microservices, is you can deploy services independently of one another.”

FROM MONTHLY SERVICE WINDOWS ON SUNDAYS…

Our old monthly release cycle was based on having a ‘service window’, usually on a Sunday morning, where we could stop all the traffic, take a backup of the database, roll out the new version of the monolith, then bring everything back up again. You’ve got the database backup to fall back on, if something goes wrong with the update. You can easily roll everything back to the state it had before the service window.

…TO SEVERAL ROLLOUTS A WEEK

So of course, initially the microservices we had were fairly peripheral to the main function of our platform, and it wasn’t a huge risk to roll out new code without the safety of a service window. So we built deployment tools that allowed us to do that. All our microservices run with at least two instances, so an update consisted of taking each instance down in turn, replacing it with the new version. If something goes wrong, it’s not hard to roll back to a previous version. It’s a little more problematic to restore previous state, but generally we have good mechanisms to re-submit failed transactions once the service is working again.

So these days we roll out new versions of our microservices several times a week, when new features are ready, and rarely have any difficulties with this. The need to roll back does occur occasionally, but more often we can ‘roll-forward’ and deploy a newer version with a fix.

“These days we roll out new versions of our microservices several times a week, when new features are ready.”

MANY REASONS TO CONTINUE ON THIS PATH

With our former monolith, the situation is a little different though. Any changes that touch the database are deemed too risky to deploy without first taking a backup, and that currently requires a service window. We’ve got so used to frequently pushing out new versions of the microservices, and seen the benefits of that, that we’d like to do the same with the former monolith.

We also have good business reasons for wanting to release without having a service window – for a start our traffic is growing at such a rate, we can ill afford any downtime. Perhaps more importantly, as we get customers in more parts of the world, a Sunday morning is no longer a ‘quiet’ time of the week when it’s relatively ok to suspend our service. In some Arab countries where we do business, Sunday is the first day of the working week.

THE SHIFT TO CONTINUOUS DELIVERY HAS STARTED

Now we’ve gained some experience with Continuous Delivery of our microservices, it’s time to do the same with the whole Pagero Online platform, including our old monolith. So I look forward to being able to soon report that we’ve got the dials going all the way up to 10 and we are deploying any part of our system at any time.