Defend the quality of your microservices - no one else will

Not all companies work with Project Mangers these days, but those that do need much thicker boxing gloves. Generally, as engineers progress in their careers, they find themselves regularly working alongside the ‘business’ people. Often those people have a general understanding of the services that your team owns and maintains but they rarely understand the tradeoffs in the the technical complexity of the architecture, especially if there are legacy components involved. And let’s face it, there are often legacy components involved.

Can you deliver this? …but why?

I recently had to say no to a decision made by these ‘business’ people. They proposed, even with the Architect’s assistance, that a legacy system should leak its implementation details to a microservice that I worked on regularly. The legacy system was throwing some kind of ActiveMQ error and they wanted me to parse it and take that as a scenario I should consider as a timeout. Not only is this is a massive violation of information hiding but why should my microservice care about the implementation details of another system? That system could change it’s implementation from ActiveMQ to something else in future and now my microservice is dependent on that change. I would have to annoyingly deploy a change to the error message exactly at the time they deployed the change to their underlying queue technology!

Put yourself in the shoes of the Project Manager. You want shit to get done and you want a clear set of requirements and the ability to know its tested and ready to go so you can move onto the next thing. As engineers we need to be empathetic but we can’t be lazy. We cannot accept every solution that comes to us just because it’s easy and by saying no it might upset others. Some might even argue that it’s our duty to say no, because, well, who else would?

Think about the business you’re a part of. Let’s say you’re working for a large company (not for a startup, in contrast). You know the people you work with theoretically should care about startups coming and taking over your turf but in your day-to-day work you don’t really touch that big picture. In a big business you have the luxury of big budgets and with big budgets the business can afford to change things slowly in the short term, playing a slow catch up to the competition and never delivering anything fundamentally new. How depressing. But you wonder, how do they keep doing it? Again and again we seem to keep showing good financial results so hey, we must be doing something right! How quickly we forget the mistakes of the past when they aren’t on our short-term radar.

A leaky legacy system, alright!

Coming back to my original dilemma, I said it wasn’t a good option an offered some alternatives, all of which were put in the ‘too hard’ basket because the legacy system was so limited in what it could do. I am happy to report that eventually the detail of the ActiveMQ implementation was not passed across to my microservice, but rather a generic error that encompassed other errors. This we already mapped and we knew generally what it meant (basically, an issue with the legacy system), and a support person could then look into the logs for the legacy system rather than it leaking details to newer, non-legacy systems. A great result all around I think.

It takes courage to say no people, especially people you don’t have a great working relationship with and you can’t relate to because they’re on the ‘is my suit dry cleaned yet?’ side of the fence and you’re on the ‘has anyone reviewed my PR yet?’ side of the fence. Think about how you’ll be perceived by fellow engineers when you defend the quality of your services. Think about onboarding a new person to your team and avoiding the story as follows: ‘yeah so we have this service, this class here yeah we have those responses because the legacy system needs them, it’s crap, I know ‘. I hate it when people say that we really need to do something about it when we could have avoided it in the first place. As I grow as an engineer I hope I can put this into practice because it is a good challenge but as we know, most problems don’t arise as a result of code but as a result of people.

I guess today I have this strong feeling to be proud of what I do. To tell people - be a damn good engineer and defend your turf, even if you inherited it. No one else will.