4 ms·

In my experience a lot of technical decisions are about solving an immediate urgent problem, not really about a true discussion of tradeoffs. I’ve seen monolith

In my experience a lot of technical decisions are about solving an immediate urgent problem, not really about a true discussion of tradeoffs. I’ve seen monoliths broken up into micro services because teams feel they can’t iterate on their problem fast enough. I’ve seen micro services turn back to monoliths because of difficult scaling/deployment/cost properties of so many little services. And then people argue from a standpoint of we had X problem we solved with microservices. People rarely feel the Y problem they’re not currently having. Add to that the bias for the new dev/leader to push some change to show impact - you get a regular pendulum swing between extremes. One problem underlying it all is stable engineering leadership. This itself is a challenging balance between stability avoiding dumb architectural churn like I describe vs ensuring you have some new blood to inspire fresh ideas. Another problem is just misatribution: we see X problem in the product, some eng pushes Y big solution to X even though there’s probably a simpler path to solving X in the current stack. Often you don’t really need to do that big revamp but to show impact? devs preference? we do X anyway.

thatsit 2y ago
Right, there is no measurements involved and most decisions are gut-based. In the end most systems will work somehow, it’s just that the pain points in development are different.
- spaceywilly 2y ago
  “In the end most systems will work somehow” The older I get the more I feel like this is a feature, not a bug. I have spent too much time over engineering systems that end up being canned because leadership decides to go in a different direction. These days I am much more concerned with striking a balance between perfect and good enough. Get something out into production, start generating some revenue and finding the stuff people like about it, then see what is giving you the most problems and fix that. That’s going to be a much more successful path than never shipping anything because of endless polishing and optimizing. If I ever find myself spending a long time debating some technical decision (aka bike shedding), I have learned to hit pause and say let’s just pick a path and go with it. As an aside this also works for deciding what restaurant to go to or what kind of pizza to order.
  - kayo_20211030 2y ago
    Completely agree. I'm personally inclined to be more toward the "good enough" end of the spectrum than the "perfect" end of the spectrum - but it's still a judgement call. Ultimately, one needs to turn out a product, make money, and fix it up where there are gaps or deficiencies. It is a feature; a good one. Anything else is just hubris and vanity. If you feel you need micro-services to force an organizational change, don't equivocate, just lead with that, and get back to business.
- softwaredoug 2y ago
  Even if there is measurement, it’s pretty easy to cherry pick stats or question the existing stats. I’ve seen it time and time again often “data driven” only matters if the data agrees with the leader/devs preconceived beliefs.

thatsit 2y ago

Right, there is no measurements involved and most decisions are gut-based. In the end most systems will work somehow, it’s just that the pain points in development are different.

spaceywilly 2y ago
“In the end most systems will work somehow” The older I get the more I feel like this is a feature, not a bug. I have spent too much time over engineering systems that end up being canned because leadership decides to go in a different direction. These days I am much more concerned with striking a balance between perfect and good enough. Get something out into production, start generating some revenue and finding the stuff people like about it, then see what is giving you the most problems and fix that. That’s going to be a much more successful path than never shipping anything because of endless polishing and optimizing. If I ever find myself spending a long time debating some technical decision (aka bike shedding), I have learned to hit pause and say let’s just pick a path and go with it. As an aside this also works for deciding what restaurant to go to or what kind of pizza to order.
- kayo_20211030 2y ago
  Completely agree. I'm personally inclined to be more toward the "good enough" end of the spectrum than the "perfect" end of the spectrum - but it's still a judgement call. Ultimately, one needs to turn out a product, make money, and fix it up where there are gaps or deficiencies. It is a feature; a good one. Anything else is just hubris and vanity. If you feel you need micro-services to force an organizational change, don't equivocate, just lead with that, and get back to business.
softwaredoug 2y ago
Even if there is measurement, it’s pretty easy to cherry pick stats or question the existing stats. I’ve seen it time and time again often “data driven” only matters if the data agrees with the leader/devs preconceived beliefs.