Just as often, the problem is that the programmer had introduced assumptions (and complexity and problems) where none were required. Did they do it just for the heck of it? Or did a stakeholder ask them to add feature X because it "would be nice to have" (maybe they just think it would be nice to have, without realizing that it is unnecessary or that they could achieve what they want in a different manner using a different, less complex feature Y)?
I'm well aware of those corner cases. And, at work, I'm dealing with.. well, not corner cases, but "real world" stuff right now, related to dates and timezones. None of what I'm doing right now would be necessary if people had the guts to decide that internally and in logs, everything is always going to be in a single format such as Unix time. Unfortunately, people made bad decisions and there are stakeholders so I'm adding complexity to the software.
If it were my software, I would outright reject this complexity. It is not needed for the software to do what its core purpose is.
People like to argue that the real world is absolute and software is strictly inferior if it cannot deal with all the complex cases people in the real world attempt to shove into the software world.
My argument is that a good engineer can look at a (seemingly) gnarly real world issue and finds a way to make it simple. Not all complexity is inherent.
Using OpenBSD after Linux is quite illuminating in this regard. At points it might seem like it's lacking features, but on the other hand you find lots of cases where it achieves exactly what you could achieve on Linux in a simpler manner and with fewer features & less complexity because they took a simpler approach to it, and in doing so, made a bunch of features a Linux user would look for simply unnecessary.
I'm well aware of those corner cases. And, at work, I'm dealing with.. well, not corner cases, but "real world" stuff right now, related to dates and timezones. None of what I'm doing right now would be necessary if people had the guts to decide that internally and in logs, everything is always going to be in a single format such as Unix time. Unfortunately, people made bad decisions and there are stakeholders so I'm adding complexity to the software.
If it were my software, I would outright reject this complexity. It is not needed for the software to do what its core purpose is.
People like to argue that the real world is absolute and software is strictly inferior if it cannot deal with all the complex cases people in the real world attempt to shove into the software world.
My argument is that a good engineer can look at a (seemingly) gnarly real world issue and finds a way to make it simple. Not all complexity is inherent.
Using OpenBSD after Linux is quite illuminating in this regard. At points it might seem like it's lacking features, but on the other hand you find lots of cases where it achieves exactly what you could achieve on Linux in a simpler manner and with fewer features & less complexity because they took a simpler approach to it, and in doing so, made a bunch of features a Linux user would look for simply unnecessary.