Simple, correct, fast: in that order • Hacker News Board

Re: Simple, correct, fast: in that order

#131

Post by AnIdiotOnTheNet » Mon, Jul 09, 2018, 3:09 PM UTC

theandrewbailey wrote: post #11

SamuelAdams wrote: post #2

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.

Agreed. Software that does what it's supposed to is better than software that is simple (or fast), but buggy.

Which is why everyone uses OpenBSD instead of making a tradeoff with a different OS that isn't designed as securely.

Re: Simple, correct, fast: in that order

#132

Post by tchaffee » Mon, Jul 09, 2018, 3:10 PM UTC

eggbrain wrote: post #33

One of the lessons I've learned (that this article echos upon) is that you should _always_ factor the "long term cost" of adding a feature. When I first started building TrueJob (job board software), I'd add in all these really cool features that made my app -- and at the time, they felt really useful. But over time, people weren't using them, so I built more features. But then the old features I had built broke, so…

I have encountered this so many times with enthusiastic and well-intentioned but non-technical founders that I created a quick presentation around it. Maybe other folks will find it useful.

https://www.slideshare.net/chaffeet/how-killer-features-will...

Re: Simple, correct, fast: in that order

#133

Post by kibwen » Mon, Jul 09, 2018, 3:19 PM UTC

Without defining what "simplicity" and "correctness" are supposed to mean, this article is empty of content. The title appears to be riffing off of the famous saying "First make it work, then make it right, then make it fast" ( http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast ) which is supposed to be a warning against premature optimization (one that is less often taken out of context than Knuth's famous saying). But by lumping both "making it work" and "making it right" under "correctness", it makes it appear that the author values simple software that doesn't do its job over complex software that does. And the problem is that you can't easily slot simplicity in by drawing a stark dividing line between "making it work" and "making it right", because it's a continuum of correctness. At best, simplicity is more important than performance, much of the time. But at the end of the day the point of software is to perform a specified task, whether or not it is achieved in an aestheically pleasing way underneath.

Re: Simple, correct, fast: in that order

#134

Post by dredmorbius » Mon, Jul 09, 2018, 3:20 PM UTC

DannyB2 wrote: post #71

When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…

Gerald Weinberg. A classic, inpired much of Demarco and Lister's Peopleware.

https://leanpub.com/thepsychologyofcomputerprogramming

Re: Simple, correct, fast: in that order

#135

Post by Sir_Cmpwn » Mon, Jul 09, 2018, 3:21 PM UTC

jasode wrote: post #122

Sir_Cmpwn wrote: post #94

Earlier quoted context omitted.

I 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.

>", 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…

You'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.

Re: Simple, correct, fast: in that order

#136

Post by kibwen » Mon, Jul 09, 2018, 3:22 PM UTC

Daycrawler2 wrote: post #118

DannyB2 wrote: post #71

When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…

That was my first thought as well but then I realized that by correctness the author means "no bug", which is quite more ambitious than just making it "work". I think the author implicitly assumes the software basically works right from the beginning of the article.

If that's the case then the author is attacking a straw man, because nobody (besides Dijkstra) is suggesting that we rewrite all the software in the world in Coq in order to 100% eliminate bugs at the cost of simplicity.

Re: Simple, correct, fast: in that order

#137

Post by masklinn » Mon, Jul 09, 2018, 3:23 PM UTC

lopatin wrote: post #26

SamuelAdams wrote: post #2

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 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.

That's a flagrant example of "simple and wholly incorrect". If you don't store timezones, your future dates will eventually turn out incorrect when timezone offsets change e.g. create a meeting at 9AM local, store as UTC, country decides to not follow DST that year bam your reminder will ping an hour early or late.

Or a day off when the country decides to jump across the international date line (https://en.wikipedia.org/wiki/International_Date_Line#Samoan...).

Re: Simple, correct, fast: in that order

#138

Post by close04 » Mon, Jul 09, 2018, 3:23 PM UTC

DannyB2 wrote: post #108

Dylan16807 wrote: post #92

Earlier quoted context omitted.

> If the program doesn't have to work, I could make it read 100 cards per second. > Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness. Correctness isn't binary. Roughly no software today is 100% correct, but for most purposes you'd still pick the current version over a highly complex, slower, more-correct version. Simplicity can save you a lot of cost as…

If correctness is some kind of continuum rather than a binary choice, then pick whatever trade offs, cost, and other factors you want. Plenty of times correctness is binary. In some cases it would be: passes all tests. Or: meets all requirements. Even if it could be "more" correct (or "more" simple), but those aren't part of the tests / requirements.

I always thought correctness begins when the result of your work does what it's supposed to do.

Maybe it's supposed to move from A to B, maybe it should do it in under x seconds, maybe it should go via Y, maybe it has to be easily understood by a 6 years old, etc.

But I can't really imagine something that has simplicity as the only requirement ("nothing" is the simplest thing so that requirement would always be met with no action). So as long as the other requirements are met simplicity is usually the nice to have "add-on". And you can have correct and simple, or correct and complex. But correct (does the job) trumps simple. And the world is surrounded by examples that prove this point.

I think the author meant "simple should be part of good design" but couldn't properly convey the message. He focused on making the message simple and ignored the fact that it's not correct.

Re: Simple, correct, fast: in that order

#139

Post by nautilus12 » Mon, Jul 09, 2018, 3:24 PM UTC

At the end of the day your opinion on this doesnt matter. The company you work for is still going to want it as fast as you can possibly manage it, and they honestly dont care if you have to write spaghetti code to get there because they dont have to deal with it.

I think I need a new job...

Re: Simple, correct, fast: in that order

#140

Post by whack » Mon, Jul 09, 2018, 3:24 PM UTC

zurn wrote: post #57

whack wrote: post #41

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…

A counter-anecdote: The features you listed started shipping (from Intel & MIPS) in microprocessors in 1996, 22 years ago. Intel's out-of-order Pentium Pro was beaten by the in-order DEC 21164 the same year. 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... )

Sure, specific optimizations in specific markets may not be worth the cost they incur. Or they may not be valuable enough to overcome other weaknesses in the project.

And yet, if someone tried to sell a server CPU today that was not pipelined, not OOO, and didn't have branch prediction, it would absolutely tank in the marketplace.

I never said that performance optimizations should always be implemented. Just that performance optimizations should sometimes take precedence over simplicity.