Comment by danpalmer
1 day ago
In my experience this doesn't happen as often as some people like to state. It tends to be less experienced, more junior, engineers that propose complex solutions, and more experienced engineers are the ones driving simplicity – both because they've been burned by complexity and value the simplicity more, and because they have the experience to clarify and distil problems down enough to get to the simplest solutions.
I think it's easy to state this sort of opinion, it sounds good on the surface, but I don't feel it stands up to scrutiny. I'd like to see some evidence or studies done to see if this is actually a trend.
I haven't worked at that many companies to have an informed opinion, but I've certainly been at a couple of places where smart people went along with ridiculous complexity, but part of the reason was there was already a hugely complicated mess with way too many people working on it for a simple solution to be politically feasible.
While the post seems simple, it's arguably complex, as the comments here point out.
Simple solutions are good enough some of the time, perhaps even most of the time, but often fall down with edge cases. But edge cases add up, and dealing with them is complicated.
For example, calculating pay for hourly paid workers is a "simple" problem. Deduct start time from end time and multiply by rate. Covers 90% of the workforce.
But the other 10% take much more work. That team that rotates an on-call worker (which earms an allowance), who gets a call (first hour is free, next is double time etc.)
So it is with software. Adding 2 numbers is trivial. But what about overflows? What about underflows? What if one number is infinity? What if it's i?
The simple solution is "just add, ignore edge cases". The complex solution handles the edge cases. Which is better in the long run?
Essential complexity is a class full of methods to compute your complicated payroll.
Unnecessary complexity is a microservice architecture to do the same thing.
I think it's important to understand the domain to know if those edge cases are likely to happen. If no one on payroll is ever on call, then no need to design for that. Solution works as intended. If it turns out we need a more robust calculator later, then we can design for that. But adding that complexity before the domain requires it seems unnecessary to me.
But also, just because there is complexity in the domain doesn't mean there needs to be complexity in the software. An elegant, simple solution could be implemented for calculating payroll or adding infinity. That's the hard part though.
This is true, I think there's also quite a lot of folks sticking their head in the sand about complexity. Software should be as simple as possible _but no simpler_, yet I see a lot of people floating "simple" solutions that don't actually meet the requirements. By all means be skeptical of requirements, but disregarding them without any work to remove them, is just bad engineering.
The engineering team at a large bank some time ago did a blog post of having over 4,000+ microservices where a single API call from the client interacts with 1,100 of those microservices. Sounds great a great architechture right? /s
Would you want to be in charge of simplifing this architecture for a 'senior staff' title for 4+ years?
This is just one of many examples who have this sort of complexity and it is celebrated, and the microservices hype (originated from Netflix and overhyped by Thoughtworks) have somewhat caused this madness and for some, it has turned into a mountain of technical debt to maintain.
Unless you have a very good reason to save a company from drowing over it's own complex infrastructure costs to run itself, attempting to simplify this architecture will be met with feroucious backlash by other teams of senior staff engineers, hundreds of meetings with risk officers and being blocked because of forever meetings with architects.
I would absolutely love to be hired to be in charge of simplifying this.
Since they made me in charge of this, at least management already is aware of the problem. Convincing Some engineers to start on a new greenfield project to replace their old solution is also not difficult.