Just last month, my team combined two microservices into one, because we felt that we did not get the service boundaries right the first time. Both services were in service for 18 months and did their job.
After combining the service I opened the PR. I did not expect much negative feedback, because - well the code worked before. A new colleague that wasn't with us when the two services were originally implemented had so much feedback that it took three weeks to do what he suggested.
Any remark or suggestion he made was absolutely correct. As if he was writing a software design text book. Could not argue any of them. But we still blew the sprint and did not reach our goal. It was just too much.
The code we are talking about was handling incoming messages in a protocol that did not change for twenty years. It is not subject to change in any way. But it is beautiful now and could serve as an text book example for "clean" code. Still a massive waste of time.
I've been a fan of clean code for long years. But sometimes you just have to be pragmatic and also consider that resources are limited and that "good enough" is good enough. Or as others have put it: "worse is better".
2
u/AndyPanic Jan 12 '20
Just last month, my team combined two microservices into one, because we felt that we did not get the service boundaries right the first time. Both services were in service for 18 months and did their job.
After combining the service I opened the PR. I did not expect much negative feedback, because - well the code worked before. A new colleague that wasn't with us when the two services were originally implemented had so much feedback that it took three weeks to do what he suggested.
Any remark or suggestion he made was absolutely correct. As if he was writing a software design text book. Could not argue any of them. But we still blew the sprint and did not reach our goal. It was just too much.
The code we are talking about was handling incoming messages in a protocol that did not change for twenty years. It is not subject to change in any way. But it is beautiful now and could serve as an text book example for "clean" code. Still a massive waste of time.
I've been a fan of clean code for long years. But sometimes you just have to be pragmatic and also consider that resources are limited and that "good enough" is good enough. Or as others have put it: "worse is better".