Interfaces and teamwork

Have you ever found it challenging to work with the people around you? Not because they're bad people, but because you all found it difficult to figure out who's doing what.

Maybe there was a lot of overlapping work, and lot of ambiguity about who was doing what, a lot of people stepping on eachother's toes without meaning to. You felt unclear about what you were building vs what others were building. For example, you would try to build something, but it turns out, someone else was also trying to build that thing. So you were doubling up on effort. And then trying to merge your code would get wierd. And you find yourself and your colleagues getting into all kinds of arguments about what this thing we are building should be and how it should work.

I recently discovered one technique, which I used in a recent project, and which seemed to work quite well.

Basically, it's using interfaces to organize teamwork.

As developers, most of us are probably familiar with the concept of interfaces. It's usually some structure that sits between one unit of code and another. So I had this idea of using an interface to make it easier to work with one of my team mates.

So we had a database that we wanted to monitor. Whenever a certain change occurred, we wanted to then go through a series of steps, and at the end of the steps, we wanted to produce some output to a few different consumers.

My job was to build the whole pipeline, but to work with the team who were in charge of the database, so they could make sure the work was done cleanly and according to their standards.

So from this brief description you can already see some trickiness and ambiguity emerging here. Here I am responsible for getting some data from a database and doing something with it, but there is this other team who are also responsible for this same database. So I needed a way to work with the team mates so I could get what I wanted, but they could also do what they wanted, with minimal fuss.

I solved this with - guess what? - an interface!

So basically I created an interface. That interface had a method which could be called whenever there was an update to the database that concerned my workflow. (I forgot the name, but it was called something like processData.)

This immediately created a nice clean separation of responsibilities.

1. All that the database team had to be responsible for was to call my method whenever the relevant part of the database was updated. As long as they called my method at the appropriate time, their job was done.

2. All I had to be responsible for was to make sure my workflow kicked off whenever that method was called. This was a matter of writing code inside the method implementation, to generate the appropriate data structures, instantiate the appropriate classes and call the appropriate methods.

This was a perfect division of responsibility. The database team could focus on what they knew well, which was the database. I could focus on what I wanted to do, which was to set up a workflow and transform the inputs into outputs.

As a side-benefit, it was super easy to write unit tests for my workflow. Rather than having to test or mock the whole database, all I had to do was mock the inputs to my interface and focus on implementing the actual thing I was building, which was the workflow.

Also it was easier to give accurate feedback to management about my progress. I could tell them about the progress I was making with the workflow, rather than being blocked by waiting for the database team to do their part of the job. The database team, likewise, were clear on what their job was, and they could steadily deliver it and give updates to managers on their progress. So everyone was happier and more productive working in this way.

After that experience, and a few others, I can definitely recommend interfaces as a way of structuring teamwork, which could potentially benefit you in your project!