Future Needs Can Focus Your Immediate Requirements

I worked recently on a microservice and attempted to implement it for one specific purpose, but at the same time, keep it generic enough for reuse across the company at a later date. Being all too aware of the problems of over-engineering I set out to experiment and try and find the right balance for my particular problem. As it turns out an interesting thing happened that I did not expect and which I would like to share today.

My intent was to build a microservice that would be used by one of the existing MYOB products but with the potential to be used by others which I knew they would need some time down the track. Obviously, unless you know your future consumers this can be a bit of a challenge, and potentially a total waste of over-engineering time. That said, I knew all the product managers wanted this feature (and immediately - as they always do), they just all had different time constraints.

Luckily I was able to get them all under the same roof before I started for a chit chat. At this meeting I told them that I was going to try and build the service for the first guy who needs it but wanted to understand and consider other's needs to find the right balance so we didn’t cut off our nose to spite our face.

Then the amazing thing happened.

The PMs and the BAs and the devs were all in there debating, arguing and negotiating - what I should do, what’s in now, what’s later, what’ll never be in, the usual, when suddenly I noticed that the scope was reducing! I did a double take, checked again, and sure enough the original conceptualised feature had over the course of the debate been reduced to a much neater essence of the idea.

suddenly I noticed that the scope was reducing!

When, in the history of computing, has having more people wanting more features all in a room together ever resulted in less features?

Ok, so that is a tad of an exaggeration, but check out this diagram which shows the end result.


Each of the three Consumers A, B & C each needed some part of the solution but at different times - they just didn't know which parts. But as each product owner described their requirements in turn the heart of the commonality started to take shape until it was down to A ∩ B ∩ C. Then when Consumer C, the team who needed the feature first, started to build they just built the intersection as the first step.

And this was a win/win/win. It helped C work out their essence, it created an asset (as a microservice) that everyone could use eventually, and it allowed us to start testing and learning with the smallest investment before everyone else jumped in.

When Consumer A or B is ready next, they will build just the common extension A ∩ B - C that they both need first.

Had Consumer C started building their solution without having this discussion first they would certainly not have identified and built the actual core and we would not have got the leverage this model offers as a whole team.

The lesson I got from all of this is that actually talking about the software architecture (i.e., microservices) with product management can actually be a good way to help them visualise the technological implications of their feature requests and gives them the tools they need to drive down features into manageable chunks that can be deployed and reused over time.

I think I’m getting the hang of this services thang.

Cover photo by Cheryl under the Creative Commons license