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

Re: Simple, correct, fast: in that order

#41

Post by whack » Mon, Jul 09, 2018, 2:15 PM UTC

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

And yet, if you try to compete with Intel with a CPU missing the above optimizations, you will get absolutely creamed in the marketplace. No one, not even those touting the importance of simplicity and correctness, will buy what you're selling.

Today's free market is too complex for these overly simple rules. Choosing between simplicity, correctness and performance, is a complex tradeoff that needs to be made on a case-by-case basis. Trying to find shortcuts to avoid these analyses may feel liberating... but you're ultimately only shooting yourself in the foot.

Re: Simple, correct, fast: in that order

#42

Post by denzil_correa » Mon, Jul 09, 2018, 2:15 PM UTC

“Everything should be as simple as it can be, but not simpler” aka Occam's razor.

Re: Simple, correct, fast: in that order

#43

Post by betacat » Mon, Jul 09, 2018, 2:15 PM UTC

How do you know how far to simplify if you don't pay attention to correctness? Simple has correct as a dependency.

Re: Simple, correct, fast: in that order

#44

Post by ioulian » Mon, Jul 09, 2018, 2:16 PM UTC

You can apply this rule to the structure of your codebase/class: make a lot of small, focussed classes rather than one big class that does everything.

This way you can easily debug it, replace the logic of 1 class without breaking your whole application.

One of the best advices for me was: your function must do one thing only, and do it good.

Re: Simple, correct, fast: in that order

#45

Post by DannyB2 » Mon, Jul 09, 2018, 2:16 PM UTC

koolba wrote: post #10

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.

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?

Re: Simple, correct, fast: in that order

#46

Post by [deleted] » Mon, Jul 09, 2018, 2:16 PM UTC

MikeTaylor wrote: post #5

This title is misleading. The post actually says that the reason "simple" comes first is because without it you can't have "correct" (nor "fast", not that that matters so much). So he's not saying simple is most _important_, just that it comes first chronologically, and has the other two as consequences.

[deleted]

Re: Simple, correct, fast: in that order

#47

Post by hoorayimhelping » Mon, Jul 09, 2018, 2:17 PM UTC

I think clear is the most important. Most software projects I've worked on in the past decade have gotten a lot of assumptions wrong. The projects that were able to turn around quickly were the ones that could find busted logic and fix it.

I've been using rspec-inspired testing frameworks to help with this clarity. Whenever I implement some early business logic, I assert that the logic I wrote does what I expect in words using rspec style tests (I've been writing a lot of JS lately so I've been using Jest). The kind that read like sentences: "the tax component applies 2% tax to all purchases above $400." Even if the logic is initially incorrect, being clear in our incorrectness lets engineers and (more importantly) product people quickly identify incorrect assumptions.

The logic to apply that tax in this example may not be simple. Often times, business logic can't be simplified any further and needs to be a bit thorny. In those cases, clarity of purpose is much more beneficial than simplicity, and I've found writing rspec style tests, and forcing myself to translate what the logic is doing into words, helps immensely with clarity. It clarifies my thoughts before shipping code, and it clarifies our business assumptions as a whole when that code is running in production.

Re: Simple, correct, fast: in that order

#48

Post by DannyB2 » Mon, Jul 09, 2018, 2:18 PM UTC

neogodless wrote: post #37

Think about it in terms of each choice you make. I have a simple solution and a complex solution. Does the simple solution meet the requirement(s) before me? If so, I prefer it. Let's move on to the next requirement and consider my options again. The alternative might be to look at your requirements, but choose a complex solution (over a simple one) because you think it might meet other requirements, either ones that…

Certainly don't gold plate.

But simply meeting requirements is only doing the minimum possible. Now in a government job, that's okay.

But in a real job, if you see where the simple solution is OBVIOUSLY wrong for certain likely cases not considered in the requirement, then THE REQUIREMENTS ARE WRONG, or incomplete and this should be pointed out!

Re: Simple, correct, fast: in that order

#49

Post by Sir_Substance » Mon, Jul 09, 2018, 2:19 PM UTC

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…

The OPs advice would probably be dissapointing if applied to making a curry too. It's fortunate he regularly used the word software throughout the blog, really.

Re: Simple, correct, fast: in that order

#50

Post by ythn » Mon, Jul 09, 2018, 2:20 PM UTC

DannyB2 wrote: post #38

martingxx wrote: post #12

Earlier quoted context omitted.

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

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

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