Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple, correct, fast: in that order

drewdevault.com

Post reply on HN
Print view View original

201–210 of 349 posts

Re: Simple, correct, fast: in that order

#201

Post by kibwen »

ythn wrote: post #114
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…

> Correctness comes first. Not always. Have you ever used a SNES emulator? There is one emulator that is more correct than all others combined - it's called BSNES and it's the most true to the original SNES hardware of all the available emulators. Yet it is horrifically memory/cpu hungry - that correctness comes at a huge cost. So no, correctness does not always come first, especially if you value other things like u…

BSNES trades off performance for emulation accuracy. Other emulators trade off emulation accuracy for performance. No widely-used emulator that I know of has any care for simplicity at all (all of them are chock full of one-off special cases to benefit specific games). This has little to do with the screed in the OP, especially given how little the OP appears to value performance.

Re: Simple, correct, fast: in that order

#202

Post by kibwen »

jpfr wrote: post #200
kibwen wrote: post #186

Earlier quoted context omitted.

> Correctness is achieved by simplicity. That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."

That's... literally what the author said. If your solution is not simple, it will not be correct or fast. Correctness may be the end-goal. But correctness is absolute. So it is a bad performance indicator to set as the goal. Yes, we can track bugs. But the absence of open bugs is no guarantee for correctness. I can never say "We are 5% more correct than last week. Keep up the good work!" Simplicity is a much better g…

> That's... literally what the author said.

Excellent, so we both agree with the author that correctness is the ultimate point and that simplicity is just a useful tool for achieving correctness. :)

> Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change.

How does one purport to measure simplicity?

Re: Simple, correct, fast: in that order

#203

Post by guiambros »

kibwen wrote: post #186
jpfr wrote: post #179

Earlier quoted context omitted.

Correctness is achieved by simplicity.

> Correctness is achieved by simplicity. That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."

> ...reinforcing that correctness is more important than simplicity

It's the other way around. Correctness is obviously the goal (and likely performance too, depending on your use case), but the way to achieve it is through simplicity. So simplicity should be prioritized - as it allows you to ensure correctness.

Re: Simple, correct, fast: in that order

#204

Post by danesparza »

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…

This makes me think of the Donald Knuth quote, "Beware of bugs in the above code; I have only proved it correct, not tried it."

More info here: https://en.wikiquote.org/wiki/Donald_Knuth

Re: Simple, correct, fast: in that order

#205

Post by madhadron »

jpfr wrote: post #179
kibwen wrote: post #170

Earlier quoted context omitted.

That quote actually refutes the OP by reinforcing that correctness is more important than simplicity. Achieving correctness is the whole point of making things simple, after all. To put simplicity before correctness would be missing the forest for the trees.

Correctness is achieved by simplicity.

No, that's just the easiest path to it if your only tool is an unaided human brain.

Re: Simple, correct, fast: in that order

#206

Post by optimuspaul »

kibwen wrote: post #186
jpfr wrote: post #179

Earlier quoted context omitted.

Correctness is achieved by simplicity.

> Correctness is achieved by simplicity. That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."

I think maybe you mistakenly assumed that response was in opposition to your comment, I read it as a simplification and restatement of what you said.

Re: Simple, correct, fast: in that order

#207

Post by hinkley »

jpfr wrote: post #179
kibwen wrote: post #170

Earlier quoted context omitted.

That quote actually refutes the OP by reinforcing that correctness is more important than simplicity. Achieving correctness is the whole point of making things simple, after all. To put simplicity before correctness would be missing the forest for the trees.

Correctness is achieved by simplicity.

    For every problem there is a solution that is simple, neat - and wrong.

Re: Simple, correct, fast: in that order

#208

Post by susam »

My approach towards software development has been pretty similar except that my order of priorities is a little different. I prefer:

Correct, simple, fast, in that order.

In other words:

- First get a correct solution working that solves the problem correctly for typical as well as corner cases, hopefully with good test coverage for both typical and corner cases.

- Then improve the solution to make it simpler while preserving correctness.

- Spend time on making it fast when there is actual evidence of performance problems such as data from performance testing with current workload and expected future workloads.

The reason why I like to ensure correctness before simplicity is that many times what might seem like a simple solution initially might turn out to be the wrong idea when all corner cases need to be accounted for. Ensuring correctness first requires me to think through the corner cases well and write test cases early during the development phase. With correctness taken care of and protected reasonably well with test cases, it becomes easier to iterate on the solution and increase its simplicity.

Re: Simple, correct, fast: in that order

#209

Post by jpfr »

kibwen wrote: post #186
jpfr wrote: post #179

Earlier quoted context omitted.

Correctness is achieved by simplicity.

> Correctness is achieved by simplicity. That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."

We reached the maximum thread depth.

>> Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change.

>How does one purport to measure simplicity?

There's 40 years of research into that. And loads of tools to support dev teams.

You can start here: https://en.wikipedia.org/wiki/Cyclomatic_complexity

Also related are costing models: https://en.wikipedia.org/wiki/COCOMO

Re: Simple, correct, fast: in that order

#210

Post by icc97 »

jpfr wrote: post #160
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…

Your example is a case of premature optimization. That is not what the author is concerned with. The problem are not the programs that obviously do not work or who break in a very visible fashion. Programs whose deficiencies are known can be fixed or worked around. The real problem are programs that appear to work correctly but aren't. To say it with the words of Tony Hoare: There are two ways of constructing a softw…

> Your example is a case of premature optimization. That is not what the author is concerned with.

I think he is. Premature optimisation is putting the order: fast, simple, correct.

So although the author doesn't explicitly state it, premature optimisation is something that would be avoided if you followed his advice.

Post reply on HN