Changes are not necessarily easy or even possible to make safely if things are correct but not simple.
"Simple" is a proxy for "can be changed safely" and so IMO is the most important quality to have.
Changes are not necessarily easy or even possible to make safely if things are correct but not simple.
"Simple" is a proxy for "can be changed safely" and so IMO is the most important quality to have.
If simplicity helps achieve correctness, then great.
But correctness is not always simple.
Most people think there is a leap year every four years. They are wrong.
Abstraction allows you to hide complexity and make it a simple, reusable part again.
Plus, a complete leap year implementation is already what I would consider simple and most standard libraries already have an implementation for it you can use directly.
In their minds, when things stop being simple, fast trumps correct.
If I'm writing a file backup program, it absolutely must back up all the files without leaving any out or corrupting the data.
But let's say it has a feature that prints progress indicator percentages on the command line, ranging from 0% to 100%. Maybe under certain circumstances (like files added to a directory after the backup starts), it prints 102%. It's not what I had in mind, nor is it something I'd call correct. But if fixing it complicates the code a lot, maybe leaving it that way is the better choice.
(This is a bit of a contrived example because you could just clip the value at 100, but you get the idea.)