9 ms·
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
by SamuelAdams 8y ago
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.
- vinceguidry 8y agoObviously to solve the problem, a certain amount of correctness is implied. But once that threshold is reached, simplicity is a better use of your time. At least, that's the thesis of the article.
- k__ 8y agoTrue. The problem is always, how to get enough correctness that your customers are happy, but don't spent too much time on it so that rivals won't overtake you.
- koolba 8y agoMy 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.
- DannyB2 8y agoEdge cases? You mean we can't test for leap year by simply checking if the year is a multiple of four?
- koolba 8y agoNo that’s a silly example. 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.
- theandrewbailey 8y agoAgreed. Software that does what it's supposed to is better than software that is simple (or fast), but buggy.
- AnIdiotOnTheNet 8y agoWhich is why everyone uses OpenBSD instead of making a tradeoff with a different OS that isn't designed as securely.
- AstralStorm 8y agoUsers go for usability features first, with an OS that is good enough. Good looks second. They can tolerate a few weirdness and quirks as long as they can get the job done without cursing the thing. They will even tolerate non critical crashes sometimes (no or little data loss). OpenBSD is not bug free at all, it is just security oriented in the implementation. Windows got traction because it has even better hardware support, a bunch of backroom OEM deals and nice UI features (at the time of 95), then went far on software availability.
- martingxx 8y agoCorrectness (and any other kind of change in behaviour) is easier to achieve if things are simple. 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.
- DannyB2 8y agoI think you do whatever it takes to achieve correctness. 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.
- ythn 8y agoThe simple thing to do then is to call an `isLeapYear` function that abstracts any complexity. Abstraction allows you to hide complexity and make it a simple, reusable part again.
- DannyB2 8y agoBut I could write a simpler (incorrect) leap year function than yours!
- ythn 8y agoYou missed the point of the article if you interpreted it as correctness being intentionally sacrificed for simplicity. 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.
- deleted 8y ago[deleted]
- rbonvall 8y agoI know a couple of guys that would probably implement isLeap by checking that the lower two bits of the year are not set, then boast about how fast it was, and finally, when told that the logic was incorrect, push back because the additional checks would make it "slower". In their minds, when things stop being simple, fast trumps correct.
- collyw 8y agoEvery piece of software that has bugs could be considered not correct, which is the vast majority of it.
- ionforce 8y agoDepends on the definition of bug.
- quietbritishjim 8y agoAll general rules like this are terrible if you apply then blindly, but can still be useful if you apply them loosely. In your example, I would take simple to mean "only use UTC". As soon as you need timezones I would say you've moved into correctness territory and need to do them all properly (you would use a good library, of course).
- meheleventyone 8y agoThe point is that it should be as simple as possible to solve the problem but no simpler.
- betacat 8y agoThis generic expression indicates why "correct" comes first. "Simple" has it as a dependency. ;)
- meheleventyone 8y agoIt's order of importance though rather than an expression of dependencies and I'd definitely err on wanting my solution to be as simple as possible over merely correct. The idea being that whilst you are solving a problem you are always striving to solve it simply and only add complexity as needed.
- aunty_helen 8y agoBut would it be better to account for non-end of year leap second additions vs something simplier that just ignores them but is wrong once every... decade?
- imron 8y agoDepends on the software.
- lopatin 8y agoI 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.
- s3m4j 8y agoIn my experience, it's been easier to push UTC time all the way from the db to the user javascript and operate on time then, than trying to manipulate time before sending to the user. YMMV, and it's only web dev.
- taeric 8y agoThis works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.
- majewsky 8y agoFor example, a task that occurs "daily at 15:00" does not always happen every 24 hours. When DST comes into effect, the interval shortens to 23 hours once.
- falcolas 8y agoOr, at "2:30 am" in the continental US can occur twice in a day, or not at all. Of course, even that isn't guaranteed, if you're in AZ. Even "notify me in exactly 24 hours has its own complications. Leap seconds will screw up your day (as will the vague request of "exactly 24 hours"). Corner cases, the bane of simplicity everywhere.
- s3m4j 8y agoTo this day, knock on wood, I have had success at voluntarily avoiding those issues ^^ (aside from school assignements)
- marcosdumay 8y ago
- tomp 8y agoIndeed. During my visit to India in February this year, I didn't even realize they were at a half-hour time-zone offset, all thanks to the miracle of modern technology (and hardworking people maintaining it).
- purpleidea 8y agoCame here to say the same thing. OP doesn't know what he's talking about.
- michaelcampbell 8y agoThe old yarn I'd heard for years is close to this. Make it work. Make it work right. Make it work fast. In that order. Now it could be argued that "work right" can be read as "make it (work right)", or "(make it work) right", or both, but I think the point of this saying is that the "fast" part should always come later.
- taneq 8y agoYep, this is the version I heard. I think the distinction between "make it work" and "make it work right" is important, though - where "work" means "solve the problem", and "work right" means "solve the problem in a robust and reliable manner." If your software doesn't solve the problem, it's useless, no matter how correct or fast it is. Once it solves the problem, then you can work on making it bug free and elegant. Once you're done with that, only then should you look at making it fast. Note, of course, that "make it fast" refers to gratuitous optimisation. If it's too slow to solve the problem, then it doesn't work, and that needs to be fixed. A similar adage states the rules of code optimisation: 1) Don't. 2) (For experts only) Do it later.
- sethrin 8y ago3) Profile before optimization.
- AstralStorm 8y ago4) After thinking how to get beat bang for buck when optimizing. Profilers don't always pinpoint the culprit.
- kungtotte 8y agoI have a hard time seeing how profilers don't at least point you in the right direction. Or are we using different definitions of the word? They tell you how much time is spent in any given section of your program. If 80% of the time is spent in 20% of the code, it's usually a safe bet that's where you should start looking!
- grok2 8y agoSo long as the software will only be shipped after all three stages, it's a useful metric to go by, I guess. It prevents you getting overwhelmed by the myriad amount of decision-making that writing software is. And also, so long as you accept the fact that you will need minor or major redesigns by the time you get to the "fast" version that is production ready.
- slx26 8y agoas I understand it, both simplicity and correctitude are requirements for most programs, but imo the article talks about the design, the writing process, where you should focus first on writing a program that's not more complex than it needs to be, because you are likely compromising the other parts too. this doesn't mean incorrect code is acceptable. in any case, I think it's also worth mentioning that the article is probably talking about "incorrect" as in "accidental bugs", not as in "purposely ignoring the complexity of the problem". with the idea of preventing over-engineering rather than dismissing the specifications of a valid solution
- Sir_Cmpwn 8y agoIf you cannot achieve correct without simple, redefine correct.
- rhapsodic 8y ago> If you cannot achieve correct without simple, redefine correct. More hand-waving.
- Sir_Cmpwn 8y agoI disagree. I just can't get more specific without specific cases to examine. Like others have pointed out, take the matter of timezones: if "correct" is defined as "handling timezones", you should instead store time in UTC everywhere and redefine "correct" to be "convert times to local time when displayed and back again when input", which can be accomplished with much smaller, simpler, and focused tools.
- jasode 8y ago>", you should instead store time in UTC everywhere It is not possible to store UTC unambiguously on the db server for all future local wall-clock times. (Previous comment about the erroneous assumption of "UTC everywhere" being a "simple solution".[1]) Therefore, redefining "correct" to be "store UTC everywhere" achieves the exact opposite: an incorrect and buggy program. That's because the "universal" in Universal Time Code doesn't apply to governments changing DST and Time Zone rules in the future. Pure UTC doesn't have enough metadata to encode future unknowns. For correct handling with zero loss of data, one must store the user's intended "wall-clock" time in his local TZ in the db. There's irreducible complexity when dealing with user-specified appointment times so an uncompromising fixation on programming a "simple" implementation with pure UTC-on-dbserver and localtime-at-only-at-browser-Javascript ... will lead to a broken calendaring program. [1] https://news.ycombinator.com/item?id=10990240 https://news.ycombinator.com/item?id=10990240
- Sir_Cmpwn 8y agoYou're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.
- JackFr 8y ago> 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. That assumes your user base is evenly distributed across time zones. The US has 6 time zones, but if you only handled 4, you'd cover 99.3% of people.
- kbsletten 8y agoThe US has more than 6. There's a big difference between Denver and Phoenix, even though they're both "Mountain Time". Grouping them together would be overly simplistic. Things like "weekdays at 10 A.M." mean different things half the year.
- cbsmith 8y agoNoop is pretty simple...
- close04 8y agoAnd if the opening statement of the article is to be considered correct, noop is by design the only way to do things since its simplicity will always win against trying to create more complex code that does the task. "The single most important quality in a piece of software is simplicity. It’s more important than doing the task you set out to achieve. It’s more important than performance. The reason is straightforward: if your solution is not simple, it will not be correct or fast." It praises a quality that is great as an add-on, not really by itself. Pretty sure everyone prefers a complex thing that "does the task" than a simple one that doesn't. Simple "helps". Simple never "does". I think the author's values are a bit mixed up.
- comboy 8y agoHe made up his mind, don't confuse him with facts.
- coryfklein 8y agoI don't think what you're saying is in conflict with the OP: > The complex problem comes later, and it’ll be better served by the composition of simple solutions than with the application of a complex solution. Complicated problem domains can be made into simple ones by breaking them down into their constituent components. You can solve time zones by having 5000 Rube-Goldberg-esque lines of if/else-if statements, or you can organize the system into simple components that build on each other. At any given component or level the problems are clear, simple, and identifiable, and the complexity arises as the components join to form abstractions upon which higher levels operate.
- AstralStorm 8y agoOr you can end up with a mishmash of components instead of statements. Premature abstraction is a kind of premature optimization, except you're not buying performance. Bad abstractions tend to stay in for a long time. What matters is clear delineation between functional components and weak binding, so that internals can change, and that the interfaces are relatively minimal.