Coming up with a greenfield microservice design with arbitrary responsibilities and intercommunication feels so stupid to me. Why not build the thing as a monolith and split parts out when you actually have scaling problems, instead of solving theoretical problems? Development velocity is going to be way higher and it gives developers a chance to discover problems without having to deal with the mental overhead of shipping N services all at once.
The value of fast iteration cannot be overstated. Build the minimum viable version of the project first, then stress test it and break parts out when needed. This is much easier if you write modular code.
> Why not build the thing as a monolith and split parts out when you actually have scaling problems, instead of solving theoretical problems?
I sometimes think programmers are the last people who should be writing software.
The personality type that likes writing code is the exact type that likes tinkering around the edge and working on hypotheticals instead of addressing the problem at hand.
One solution is to have the senior ones (who have already been-there-done-that and lost interest in those possibly low quality outcomes or low velocities from a business perspective) handle architectural decisions and keep things on the rails by way of writing issue specs that the juniors (with those green personalities) will implement, reviewing their code, mentoring them, etc. -- carefully matching an ideal threshold of autonomy for each programmer which will relax over time.
I often see technologies adopted simply because they are the “latest and greatest” and “I want to stay relevant for my next job interview,” rather than sound technical reasoning. Unfortunately, these decisions are made by humans and those humans have lots of cross-cutting decision criteria. It’s a rare and highly mature engineer who can look at a problem and say “This old technology is a perfect fit.”
This is an organizational/tech leadership problem. Good technical leadership will put a kibosh on working on hypotheticals, because what you don't do is as important as what you do.
Good programmers pride themselves on striking compromises and shipping a smaller thing sooner and they love iterating. The ones that are working on hypotheticals unchecked are not bad--just nobody has educated them.
Coming up with a greenfield microservice design with arbitrary responsibilities and intercommunication feels so stupid to me. Why not build the thing as a monolith and split parts out when you actually have scaling problems, instead of solving theoretical problems? Development velocity is going to be way higher and it gives developers a chance to discover problems without having to deal with the mental overhead of shipping N services all at once.
The value of fast iteration cannot be overstated. Build the minimum viable version of the project first, then stress test it and break parts out when needed. This is much easier if you write modular code.