alt Hacker NewsWhile 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?
Replies
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.
Essential complexity is a class full of methods to compute your complicated payroll.
Unnecessary complexity is a microservice architecture to do the same thing.