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

291–300 of 349 posts

Re: Simple, correct, fast: in that order

#291

Post by rhapsodic »

jerf wrote: post #288
rhapsodic wrote: post #286

Earlier quoted context omitted.

>Sure... but define "correctness". How about this, for example: The patient lives.

A nice snarky reply. But I would put $10 down that if I asked you to assert that all medical software in current use that has never killed a patient because of its software issues is therefore "correct", you'd walk back hard. You'd have to be crazy to assert that all such software is "correct". Unless you are willing to make that assertion, you don't really mean that as a definition. This is also an example of what I…

>But I would put $10 down that if I asked you to assert that all medical software in current use that has never killed a patient because of its software issues is therefore "correct", you'd walk back hard. You'd have to be crazy to assert that all such software is "correct".

I made no such assertion. That's a straw man.

But I think I can safely assume that if the patient dies as a result of the software's functioning, that software is not "correct".

You may disagree, but I think it's preferable to have a patient kept alive by an overly-complex system than killed by a simple, elegant, incorrectly functioning one.

Not to be intentionally blunt or snarky, but I think Drew DeVault's post was a bunch of rambling, hand-waving nonsense. Until today, I wouldn't have expected anyone to seriously argue that simplicity is more important than correctness. But he comes along and makes that very argument, with a self-assured, authoritative tone, but very little in the way of concrete reasoning, and to my surprise, the number of people on HN who apparently agree with him is non-zero.

Re: Simple, correct, fast: in that order

#292

Post by eikenberry »

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…

I don't think this is the form of correctness discussed here. I believe this is more the Correct as discussed in the famous "Worse is better" article.

Re: Simple, correct, fast: in that order

#293

Post by HankB99 »

collyw wrote: post #20
jasonkester wrote: post #9

My take on this from like 10 years ago: http://www.expatsoftware.com/articles/2007/06/getting-your-p... I came up with Readable as the top priority, followed by Debuggable and Maintainable. I suppose one could combine that into "Simple" if one liked. But yeah, Fast was already at the bottom of the list. Even back then.

Those three properties are very highly related. Personally I found the biggest improvement to my own software came from maintaining the same system that I wrote for 4+ years. If I came back to a part and didn't understand it more or less immediately, then it was time to refactor it. I wrote the code I should understand what it is doing. No excuses that someone else had written bad code.

"It was hard to write, it should be hard to understand." (I was joking, of course, when I said this.) It seems to me that that's a reasonable metric for determining if something was well written or possibly well commented. I had an opportunity to go back to some of my older code about a year ago. It was scary to me what portion of it I no longer understood. Worse yet, portions of it referred to documentation that I could no longer find. The company had migrated their documentation through several storage organization technologies and no one seemed to know where the old stuff went. Luckily I ran across a retired engineer who recalled where a lot of it had been archived.

(Unrelated) When I read the article, the first thing I thought was that all of the simple programs had already been written.

Re: Simple, correct, fast: in that order

#294

Post by chillacy »

kibwen wrote: post #172
SuddsMcDuff wrote: post #163

Earlier quoted context omitted.

The thing is, correctess is often a transient property. Requirements are frequently changing or evolving. What's correct on a Tuesday may no longer be correct by Friday. Under these conditions it's important that the software be amenable to change. It's for that reason I believe simplicity is more important than correctness.

Simplicity is also a transient property. > Under these conditions it's important that the software be amenable to change. At the same time, under all conditions, it is important that the software actually works (i.e. correctness), which is why it's more important than simplicity. Irate users who come to us telling us that our program doesn't work will find little comfort as we regale them with how simple it is. First…

I encountered a similar argument in Clean Architecture by Robert Martin of correctness vs maintainability, where he argues for maintainability over correctness. The argument goes that if you had to choose between code that did the wrong thing but was easy to make do the right thing, and code that does the right thing but is hard to change, you should always pick the former.

He also talks more abstractly about the value of software (as opposed to hardware for instance) being primarily in its "soft"-ness, or ease of changing.

Ultimately this comes from his point of view as an architect, who fights more for system design than say, a PM might for user features. I've encountered the opposite school of thought that says: MVP to deliver features, refactor/rewrite later. I think the strategy to use will depend on the project and team (budget, certainty, tolerance for failure, etc)

Re: Simple, correct, fast: in that order

#295

Post by rhapsodic »

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.

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

If that's what he meant, he's flat wrong. Simplicity is neither necessary nor sufficient for correctness.

Re: Simple, correct, fast: in that order

#296

Post by swsieber »

wellpast wrote: post #290
tacon wrote: post #257

Earlier quoted context omitted.

You are making the common mistake of confounding essential complexity with accidental complexity. One you are stuck managing and one you can eliminate with skill. The world isn't getting less complex just because you work harder on your software.

The world, from software’s perspective at least, isn’t growing in complexity. What leads one to that?

The world growing more complex from the software's perspective.

And by that I mean, it has to account for more scenarios or do additional things... unless your software is growing in complexity while you're only removing features...

Bugs in software come from thinking we're simplifying the world in one way though the program, while in reality it receives a slightly different picture.

Re: Simple, correct, fast: in that order

#297

Post by Const-me »

TLDR: there’s no universal criteria for code quality.

Imagine you have 5 programmers. #1 works in a web development company, writing a CRUD web app in SQL, PHP and JavaScript. #2 is coding C and developing an embedded firmware for a PC component. Also works on the driver for that component in the Linux kernel. #3 writes some COBOL for a half-century old system running in a bank. #4 works in a game studio developing a level editor for yet to be announced videogame. #5 is a researcher working in a university, mostly writing Mathlab but occasionally some Python and R.

The ideal simplicity/correctness/performance tradeoff is totally different between the five. Just like any other tradeoff, or generalization, or methodology, or approach. All 5 are writing code, but the software they’re creating have totally different requirements, expectations, lifetime and budget.

I never saw articles generalizing stuff across all engineers: aircraft, biomedical, marine, telecommunications, etc. However, I saw many articles, this included, that tries to generalize across all software development.

Re: Simple, correct, fast: in that order

#298

Post by tacon »

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…

I am reminded of this classic snark from The Elements of Programming Style (1974)[0]:

"Some compilers allow a check during execution that subscripts do not exceed array dimensions. This is a help … many programmers do not use such compilers because “They’re not efficient.” (Presumably this means that it is vital to get the wrong answers quickly.)" (Page 85)

[0] https://en.wikipedia.org/wiki/The_Elements_of_Programming_St...

Re: Simple, correct, fast: in that order

#299

Post by sgt101 »

kibwen wrote: post #128
sgt101 wrote: post #116

Earlier quoted context omitted.

Works today , but tomorrow the complex solution does not do what is needed and presents a barrier to delivering what is needed now. In a static environment you are right, but static environments are vanishingly rare for software, by definition (because with stops after one iteration!)

What is this comment trying to say? That a simple program that doesn't work today is better than a complex program that works today, but that might not work in some nebulous future? Not all complexity is reducible. The point of software is to work correctly, not to satisfy the author's aesthetic notions, which is what most of the modern hype over simplicity boils down to.

What I am saying is that a ball of mud that passes all tests is worse than something clear that fails corner cases (genuine corner cases) because sorting that out can be done. Whereas the ball of mud will definitely fail in the future and when it does nothing will help you apart from a complete rebuild. "It passes the tests" simply doesn't cut it.

Re: Simple, correct, fast: in that order

#300

Post by davidgay »

fwip wrote: post #268
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…

They did use OP's strategy in the CPU industry. The first CPUs were simple as heck. They spent 20 years making them reliable(and faster without compromising simplicity, mostly just node-shrinks), and they've only really been complicating the architecture in the last 30 years.

iAPX432
Post reply on HN