Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

> 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 you edit the software, which helps you make it correct sooner. Simplicity and correctness go very well together.

View on HN

Simplicity (however it is vaguely defined) is desirable, but at the end of the day it is a vehicle for correctness, and hence necessarily subordinate to it. Correctness is the destination of any piece of software (ultimately the goal of any piece of software is to work), and simplicity is just one route to it.

> Correctness is the destination of any piece of software

"Good enough" is the destination of any piece of software. Sometimes that means correct, but more often it means "oh yeah, sometimes it starts acting funny, just restart it when that happens"

It never means "correct". Not to mention that 100% correctness is even impossible.

> Not to mention that 100% correctness is even impossible.

In which case please consider that everyone here is using "correctness" to mean "correctness that is achievable by reasonable human effort". :P It's easy to win any argument by taking one side to its logical extreme and asserting that it is therefore impossible, but that doesn't create a useful discussion. By the same logic we could assert that 100% simplicity is impossible, but that would be just as silly.

They said "destination" being correct, with me interpreting "destination" in the sense of "goal." My point was that some software has the goal of being 100% correct, but most software does not.

Agree. And "good enough" depends on your use case.

Seems a bit like the "worse is better" philosophy :

    It is slightly better to be simple than correct.

See https://en.m.wikipedia.org/wiki/Worse_is_better

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

It depends on the severity of a bug. If it's very severe, you'll favor the complex but more-correct solution. Otherwise, you'll favor the simple but more-often-wrong solution - because it's easier to fix and get progress.

I use more-* phrases because it's always in a relation. Even NASA can't claim to have 0 bugs although people die if they fail.

bit OT: There's a great article about NASA programming: https://www.fastcompany.com/28121/they-write-right-stuff

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.

I’ve noticed a pattern where the simplest solution DOES accomplish the goal, but isn’t what a user might consider the “shortest path”. How do you count a workaround where it technically can accomplish the end result, but requires a minor annoyance? What about a major annoyance?

What about a process so painful nobody has even thought of it?

It's nigh impossible to solve any complex issue with the "simplest solution" from the first try. This means that when you're faced with a complex issue you will postpone the fix because it's not the simplest.

And you never know if it can be done in an even simpler fashion later.

This seems to mix correctness and completeness.

A good program does only the correct thing in a particular area. It is known to be reliable in that area, sometimes even formally proved to be so.

Outside that area, an ideal program refuses to work, because it detects that it cannot obtain the correct result. This is normally called "error handling".

There's also some gray area where a program may fail to reliably detect whether it can produce the correct result, given the inputs / environment. A reasonably good program would warn the user about that, though.

A "garbage in, garbage out" program is only acceptable in very narrow set of circumstances (e.g. in cryptography).

Agree. In many (most?) cases there is no formal, verifiable correctness proof. And then you are way better of with the simpler solution once feedback from the real world arrives.

Reply on news.ycombinator.com