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

221–230 of 349 posts

Re: Simple, correct, fast: in that order

#221

Post by sreque »

My reaction to both the title is similar to that of other commentors: correctness should go first!

However, the general idea appealed to me, so taking a step back, I tried to post-rationalize a similar thought to the author that I could reconcile with my initial reaction. The thought I then had, is that if a simpler solution can be found that solves a significant subset of the problem being solved, then perhaps it is worth adjusting requirements to go for the simpler solution for the fact that it lets us ship faster and with less risk.

Often times we come up with requirements that aren't really "required": showing business stakeholders that dropping a few requirements could enable you to ship six months faster and with far less risk can be a valuable insight in of itself. In essence we are still putting correctness first, but we are changing our definition of "correct" slightly in order to increase simplicity.

Re: Simple, correct, fast: in that order

#222

Post by AstralStorm »

lubujackson wrote: post #218
kibwen wrote: post #149

Earlier quoted context omitted.

> Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness. Seconded. I'm highly confused at how many upvotes the OP has gotten in such a short time despite appearing to say that implementation details matter more than program output. A beautiful machine that doesn't work is, at best, a statue. I'm all for the existence of pretty things that do not need to demo…

To defend the idea, I think it starts with the assumption that software is often a moving target so "correctness" is at best a temporary state. If you had to use a codebase at any point of time you would obviously want the correct one, but if you look at the lifespan of software it would be better to have the simpler code. Simpler is (usually) easier to fix, easier to extend and easier to learn. I think the author ma…

Easier to fix, yes. Tends to get more complex in nasty and ugly ways.

Easier to extend, almost never. Proper design for extensibility has an extra bit of complexity over the most obvious. Simplistic implementations tend to be tossed away and are good for unscalable prototypes.

Easier to learn, definitely not. The simplest code comes from deep understanding of problem domain and algorithms. It is almost exactly like with writing brevity while not losing the point. It is easy to end up with simplistic instead of simple. There is that famous quote by Dijkstra which I'd rather not butcher from memory.

Re: Simple, correct, fast: in that order

#223

Post by tensor »

zzzcpan wrote: post #196
kibwen wrote: post #190

Earlier quoted context omitted.

> It may be worthwhile distinguish between general correctness and full, as close to 100% provable correctness as you can get. Which is the root of the endless back-and-forth in this thread: a program has to do what it says on the tin ("general correctness") before anything else, and then probably be as simple and as "fully correct" as possible. But it's easier said than done for us to posit a distinction between gen…

There is no line between the two. It's something that depends on how much effort and time is put into this, what methods were used, etc. But, the world doesn't actually care about this specific property, as it has no inherent value. Instead we have various levels of assurance of more practical properties, like safety, but not correctness.

I assure you the world cares if your algorithm is generally correct, passing unit and integration tests, etc. This is a programming basics.

Re: Simple, correct, fast: in that order

#224

Post by bhandziuk »

jerf wrote: post #121
ddellacosta wrote: post #64

I can't really understand the equivocating tone a lot of folks are taking in response to this, and more importantly I can't wrap my head around how you could make such a statement in the first place: without correctness you've got nothing. Stating authoritatively that correctness comes after...anything is incomprehensible to me. It's possible to have a correct solution that is neither simple nor fast, and it can be w…

"without correctness you've got nothing." Sure... but define "correctness". Suppose my manager comes to me with some incredibly complicated problem. It's going to take six months to solve properly. Suppose in the first three weeks I implement a program that is 98% correct, and let's say it can detect the other 2% and kick it out for a human to solve. But it clearly does not fully and correctly eliminate the problem a…

But this is what ddellacosta is saying. I imagine his interpretation of this argument (and I agree) is that 98% correct IS prioritizing correctness. A very fast, simple solution that is 2% correct is an unacceptable balance.

Re: Simple, correct, fast: in that order

#225

Post by jpfr »

jpfr wrote: post #209
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."

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

> The idea that simplicity (which I'm pretty sure that nobody in here is using to specifically mean "the lack of cyclomatic complexity") can be measurably improved but that correctness cannot is incorrect.

Have you seen a program that comes with a formal proof of correctness? I have. And boy, they are really simple.

The end result can be complicated. But the program is broken up into small, simple, easy-to-understand pieces that are then composed.

http://spinroot.com

https://frama-c.com

Re: Simple, correct, fast: in that order

#226

Post by p0nce »

kibwen wrote: post #198
p0nce wrote: post #167

Earlier quoted context omitted.

> Simplicity always comes after correctness. Strong disagreement here. A program that isn't kept simple will stop being correct, fast, or any desirable quality over time.

Nobody's saying that simplicity is unimportant, but if the failure mode of a loss of simplicity is that the program is no longer correct, then it inherently suggests that correctness is the primary metric to strive for. :P

Ability to change ("simplicity") is the key metric that allows to maintain, or further desirable invariant. eg: in b2c "correctness" may be less valued than another trait. Do you prefer to know something or to be able to learn fast?

Re: Simple, correct, fast: in that order

#227

Post by jessaustin »

kibwen wrote: post #175
zzzcpan wrote: post #171

Earlier quoted context omitted.

Why do you equate working software with correctness? Software that works is never correct by any definition of correctness. Because working software is a system that exists in the real world and therefore can never have a specification against it.

> Why do you equate working software with correctness? Because the original author neglected to provide an adequate definition of correctness, thereby inspiring an epic HN flamewar as people now must run around endlessly debating semantics. :P

Sometimes people say things that might not be literally true or even "true in spirit", not because they are lying liars who love to lie, but because relating an exaggeration or a caricature or some other sort of not-totally-true thing will have a better effect on their audience than the strict truth would have. As we're now up to 17 comments you've made here emphasizing the skepticism you have for TFA's message, it seems that you value the "correct" more than the "simple". It could be that you are in the intended audience for TFA...

Re: Simple, correct, fast: in that order

#229

Post by nickpsecurity »

jpfr wrote: post #209
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."

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

Derek Jones argues McCabe Complexity and COCOMO were scientifically unsupported with little bandwagons pushing them for reasons of fame and/or funding:

http://shape-of-code.coding-guidelines.com/2018/03/27/mccabe...

http://shape-of-code.coding-guidelines.com/2016/05/19/cocomo...

Re: Simple, correct, fast: in that order

#230

Post by AstralStorm »

kibwen wrote: post #161
KirinDave wrote: post #153

Earlier quoted context omitted.

That's not what Coq would do, and a misrepresentation of Dijkstra's position. We certainly could use tools like TLA+ to assist us with existing code. Folks are using "simple" and "easy" interchangeably here. That's probably inappropriate.

I apologize for using Coq speicifically, I just needed a scapegoat for formal verification that people might have actually ever heard of. :P I'm happy to debate definitions, which the author of the OP has regretfully omitted (and the contentious definition here is probably the OP's notion of correctness, rather than their notion of simplicity).

You'd be surprised how simple a well written proof can be compared to a program implementing an algorithm to do the same.

That said, Coq itself is not the best vehicle for this. There are nicer high order logic languages.

Post reply on HN