Under the hood part 2 – Just like Turner & Hooch

I really like buddy cop films. You know the ones – two mavericks who have always gotten results by doing things their own way are teamed up. Riggs & Murtaugh, Tango & Cash, Angel & Butterman. Maybe they rub each other the wrong way at first, but in the end they crack the case, get the killer, defuse the bomb. And they learn a little bit about each other on the way. That’s a pretty good description of how the dev team gets things done at Cemplicity, usually with less friction and far fewer car chases.

Last time my co-owner and I wrote about how the Cemplicity development team categorise our work to balance strategic against tactical, small against large. Once we’ve decided it’s time to work on an item, we figure out who is going to own the work. No matter how large or small the work item is, we find an owner – and a co-owner.

Before I tell you what co-ownership is, it might be worth describing what it is not.

You’re probably familiar with the concept of pair programming, where two people sit at a keyboard and work on a piece of code together. It can be useful to work in this way – collaboration is easy and there’s plenty of scope for learning from each other. But writing and reviewing the code is only one step in moving a post-it from ‘to-do- to ‘done’ – and often the smallest part.

Co-ownership is far more than just a second set of eyes on the code. At Cemplicity, when two people take ownership of a piece of work, they are assuming responsibility for the full journey of the work from initial analysis and design, through development and testing, all the way to deployment into our production environments and post-deployment support.

So how do we determine the best people to co-own a work item? There’s no formal process, but we tend to consider several variables:

First we check who is available to do the work – while it’s possible for one person to co-own multiple work items simultaneously, too much context switching is bad, so we try and keep individuals focused on a small number of items at any time.

We consider who might have the best expertise for the work. We have a diverse collection of skills and a number of different areas of code. If the work item is mostly focused on the front end of our reporting portal, we might select someone who has the strongest JavaScript chops, or someone who recently made a change in the same area. Or we might not – pairing someone who is an expert in an area or technology with someone who is still learning is a great way to share knowledge.

Sometimes we might pair up two co-owners because they haven’t worked together for a while. Sometimes there are only a couple of people free to do the work, so they get assigned the case.

Once we have our co-owners, it’s up to them how the work proceeds. The first thing they’ll do is have a conversation about the work. They might prototype several different approaches, have design sessions, create documentation… or they might just have a two-minute conversation and get it done. Every piece of work will carry different risk, size and complexity that shape the approach to this initial conversation

While the co-owners are responsible for the work item being completed, this does not mean that they need to perform all of the work themselves. They may bring in business or technology experts for consultation, loop in other team members for advice, testing, documentation, or even writing code. A major aspect of co-ownership is making sure the work gets done- it’s less important who is actually doing it.

Let’s assume our co-owners have picked up a pebble-sized piece of work. They’ve had a conversation and planned their approach to the work. They have a design and it’s time to start writing some code. There are still decisions to make. How do they divide up the work? Does one person focus on code while the other is responsible for documentation and testing? Do they use a pair programming approach? If changes are required in a number of different areas of the codebase, do they split up the work along those lines? For example, if the co-owners have determined changes are required in both the UI and database layers, does each co-owner take a slice and they work on them simultaneously?

It depends. It’s up to the co-owners to make that call and they may well make a completely different decision on the next piece of work.

One really nice aspect of our co-ownership model is that there are very few fixed rules. The co-owners, along with anyone else working on a particular work item have a great deal of autonomy in determining how they want to get things done. A quick fix is a different shape to a large architectural change. With co-ownership, the people doing the work decide how much design, testing and documentation is appropriate, which means they are actively thinking about design, testing and documentation. The documentation produced isn’t there because we have a rule that ‘you must have documentation’. It’s there because the co-owners decided that particular documentation was required.

Once the co-owners are satisfied that a work item is complete and has met their quality requirements, it’s deployed to production. But that’s not the end of the work. The co-owners are responsible for keeping an eye on the fresh code, making sure it works as intended and doesn’t introduce any unwanted side effects. Monitoring the work item might continue for days, or even weeks depending on the change made.

There are plenty of benefits to our co-ownership model. It helps us learn from each other, and not only how to better use our tools and technologies. We all have different working styles. We think about problems differently. And we like to communicate in different ways. It’s never fun when you’ve been looking at a problem for so long you’re lost in the detail. Having a co-owner can help here. Quite often they haven’t gone down the same rabbit hole and can provide a different perspective.

When you first start operating in this way, work can sometimes feel slower. It takes time to communicate your ideas and it can feel frustrating when you know this is just a five-minute job that doesn’t require extensive testing. But rather than focus on the speed of getting an individual work item through the process, we’re optimising for the overall sustainable throughput of our team. This takes into account the team dynamic and code quality, professional and personal growth, and knowledge sharing. A work item might take longer, but when it’s done, it’s done, and it’s done well.

So big or small, simple or complex – if you try and crack the case by yourself, there’s a pretty good chance the bad boys will get you. Every Turner needs his Hooch.

Next time we’ll talk about how we keep focused on improving as a team.

SEE OUR SOFTWARE IN ACTION