>The last, and most effective in my opinion, is to go with a service-based, incremental approach.
I was once handed a project where the original architect drank the microservices kool aid. It didn't stop the different services from being tightly coupled to one another - it just made the pain of that happening worse.
It made testing a pain - you needed to set up and run 11 different services on your machine to test anything.
It made debugging a pain - you had to trace calls over multiple different services with code often written in different languages. Debugging became more and more like detective work.
It created a multiplicity of irritating edge cases. The 'calculation server' could time out if it took too long - and it sometimes did. Serialization/deserialization was also an area rife with bugs.
The code quality got worse due to this approach, exacerbated by the team lead at one point giving people 'responsibility' for different services to different people.
I think microservices where they've "worked" has typically been a path of least resistance to realizing Conway's law - a tacit acknowledgement that different corporate fiefdoms want to write and deploy code in their own way and won't communicate effectively with one another. In that respect I think it's effective because it's easier to draw up REST API contracts between disparate often different-language-speaking teams using microservices than it is to draw up library API contracts.
Surrounding technical debt with integration tests and incrementally refactoring (decoupling modules, deduplicating code and adding assertions) is the only way to approach technical debt.
>In the end, overcoming tech debt is about people.
No. It's a technical problem. People problems definitely exacerbate it - deadlines, politics, etc. but it's still a technical problem in the end.
> It made testing a pain - you needed to set up and run 11 different services on your machine to test anything.
That is explicitly not the "microservices kool aid." The first thing a microservice needs to be is independently testable, so it can be independently developed.
I was once handed a project where the original architect drank the microservices kool aid. It didn't stop the different services from being tightly coupled to one another - it just made the pain of that happening worse.
It made testing a pain - you needed to set up and run 11 different services on your machine to test anything.
It made debugging a pain - you had to trace calls over multiple different services with code often written in different languages. Debugging became more and more like detective work.
It created a multiplicity of irritating edge cases. The 'calculation server' could time out if it took too long - and it sometimes did. Serialization/deserialization was also an area rife with bugs.
The code quality got worse due to this approach, exacerbated by the team lead at one point giving people 'responsibility' for different services to different people.
I think microservices where they've "worked" has typically been a path of least resistance to realizing Conway's law - a tacit acknowledgement that different corporate fiefdoms want to write and deploy code in their own way and won't communicate effectively with one another. In that respect I think it's effective because it's easier to draw up REST API contracts between disparate often different-language-speaking teams using microservices than it is to draw up library API contracts.
Surrounding technical debt with integration tests and incrementally refactoring (decoupling modules, deduplicating code and adding assertions) is the only way to approach technical debt.
>In the end, overcoming tech debt is about people.
No. It's a technical problem. People problems definitely exacerbate it - deadlines, politics, etc. but it's still a technical problem in the end.