51–60 of 349 posts
Some other formulations: - Occam's razor https://en.wikipedia.org/wiki/Occam%27s_razor - "Simplicity is the ultimate sophistication" (Leonardo da Vinci) - "Less is more" (Mies Van Der Rohe) - "Make everything as simple as possible, but not simpler" (Albert Einstein)
Like saying leap years occur every four years. Simple!
The simplest code is an empty file. And yet, we live in a world with complex software. There are tradeoffs, but this article doesn't help you make them.
> this article doesn't help you make them Sure it does. It clearly states that sometimes new features or performance optimisations have to be sacrificed to keep the software simple.
By adding a lot more complex code can I make this blitter 100 times faster? By using this more complex algorithm can I make a "simple" string search amazingly faster?
As for features: Word has more features than Notepad. So why doesn't everyone use notepad?
I would argue that correct is more important than simple. Consider timezones: it's simpler to pretend there's 24 time zones, one for each hour. But the correct assertion is there's 37 time zones (as of this writing). So, the simple solution results in a third of your potential user base having issues. Other issues to pick: accessibility, cross-browser compatibility, legacy device compatibility... the list goes on.
I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones.
I would argue that correct is more important than simple. Consider timezones: it's simpler to pretend there's 24 time zones, one for each hour. But the correct assertion is there's 37 time zones (as of this writing). So, the simple solution results in a third of your potential user base having issues. Other issues to pick: accessibility, cross-browser compatibility, legacy device compatibility... the list goes on.
The OP's advice, if applied in CPU industry, would be disastrous. Modern desktop/server CPUs are incredible complex... in order to drive maximum performance. Pipelining, OOO execution, branch prediction and speculative execution: these are all features that introduce tremendous amount of architectural and design complexity. In many cases, they also harm correctness, because they can lead to functional and security bu…
The OP's advice, if applied in CPU industry, would be disastrous. Modern desktop/server CPUs are incredible complex... in order to drive maximum performance. Pipelining, OOO execution, branch prediction and speculative execution: these are all features that introduce tremendous amount of architectural and design complexity. In many cases, they also harm correctness, because they can lead to functional and security bu…
Also, there's the case of Intel losing to in-order ARMs in mobile. First with XScale, and later on with the in-order Atoms. (https://appleinsider.com/articles/15/01/19/how-intel-lost-th...)
First of all the software needs to be correct, if the software produces incorrect results, then there is no point for it to exists. It needs to be debugged until the results are correct.
Then fast. The point of using software is helping the user to accomplish a task. The better help that the software can provide, the more useful is the software, and performance is often critical to help the user.
Then simplicity, simplicity help future developers to understand how the software work and how to properly maintain it. But if some complicated procedure is needed to produce the correct results, then complicated procedure it is. If a different algorithm needs to be used to speed the software, then the new algorithm it is. It is up to the next developer to study and understand what was done and why.
The purpose of software is the end user. The next developer sits second to the end user.
Simple, and still correct, is often the result of doing MORE work to achieve it.
Earlier quoted context omitted.
My read of this that simple means not necessarily handling all possible edge cases yet having enough of a skeleton in place that the core functionality is there. Correct is extending (or replacing) that skeleton with coverage for all cases.
Edge cases? You mean we can't test for leap year by simply checking if the year is a multiple of four?
I meant more for dealing with edge cases like an external API invocation failing. A final “correct” implementation would need to handle failures but an initial simple one would only handle success.