4 ms·

>teams of career software bureaucrats who exist to choke out companies to their last breath. Companies will go underserved for decades while underfunded project

>teams of career software bureaucrats who exist to choke out companies to their last breath. Companies will go underserved for decades while underfunded projects fail to replace a monolith one after another. All crossroads lead to the monolith that was written in some language that died 30 years ago, performs like it did 30 years ago and is maintained by people hired 30 years ago — creating imminent crises with their looming retirements. None of this seems like a monolith problem, it seems like a very-legacy codebase at a non-tech company problem.

lolinder 4y ago
I think their point is that trying to continue to work inside such a monolith is soul-crushing, but attempts to replace the monolith in one step fail because it's too big. I do think there's some confusion, though, because microservices are not the only solution to this problem. You can solve it with two services: the big legacy service hosts all the logic you haven't cleaned up yet, the small-but-growing modern service has the logic that you've cleaned up and made livable. This way you don't have to replace the old monolith in one step, but you also don't need to go to microservices—the target is still one well-factored monolith. (Edit: there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services...)
- aliswe 4y ago
  > there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services I would call that risk a guarantee. And as long you havent turned the other off, the net result is negative. I say, make the journey as valuable as the goal, and make incremental improvements that offer value from day 1.

4 ms·

>teams of career software bureaucrats who exist to choke out companies to their last breath. Companies will go underserved for decades while underfunded project

by thfuran 4y ago

lolinder 4y ago
I think their point is that trying to continue to work inside such a monolith is soul-crushing, but attempts to replace the monolith in one step fail because it's too big. I do think there's some confusion, though, because microservices are not the only solution to this problem. You can solve it with two services: the big legacy service hosts all the logic you haven't cleaned up yet, the small-but-growing modern service has the logic that you've cleaned up and made livable. This way you don't have to replace the old monolith in one step, but you also don't need to go to microservices—the target is still one well-factored monolith. (Edit: there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services...)
- aliswe 4y ago
  > there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services I would call that risk a guarantee. And as long you havent turned the other off, the net result is negative. I say, make the journey as valuable as the goal, and make incremental improvements that offer value from day 1.