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

271–280 of 349 posts

Re: Simple, correct, fast: in that order

#271

Post by jeremya »

I think this article may be guilty of overstatement. It's an ever more common sin, as overstatement seems have become a preferred method for communicating thoughts and ideas (and products, though that's nothing new).

Is there a need to overstate to cut through the noise and get your point across or your message heard? Maybe, but it seems unfortunate that when people have some truth or wisdom to share, there is a felt need to amplify and polarize it.

This article has good things to say about the importance of simplicity in code and implementation. I'm fine with value judgements as long as they convincingly define the values they are judging and show evidence that the facts have been thoroughly weighed. 'Correctness' is an ill-defined villain here and the article would do better to state the benefits of simplicity and experiences the author has had with systems designed without simplicity as a first-order goal.

Then again, perhaps I ask too much. Also, I've never had an article on the front page of Hacker News, so what do I know.

Re: Simple, correct, fast: in that order

#272

Post by kungtotte »

AstralStorm wrote: post #242
sethrin wrote: post #188

Earlier quoted context omitted.

3) Profile before optimization.

4) After thinking how to get beat bang for buck when optimizing. Profilers don't always pinpoint the culprit.

I have a hard time seeing how profilers don't at least point you in the right direction. Or are we using different definitions of the word? They tell you how much time is spent in any given section of your program. If 80% of the time is spent in 20% of the code, it's usually a safe bet that's where you should start looking!

Re: Simple, correct, fast: in that order

#273

Post by mockingbirdy »

kibwen wrote: post #144
Dylan16807 wrote: post #92

Earlier quoted context omitted.

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

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.

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

Re: Simple, correct, fast: in that order

#274

Post by nojvek »

karmakaze wrote: post #236
jpfr wrote: post #160

Earlier quoted context omitted.

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…

Depending on interpretion of terms, I'd agree with either simplicity or correctness first. To disambiguate I would say: Working, simple, correct, optimized.

Would deffo agree to this.

My approach is usually sending out a PR as soon as I can to a group of reviewers / users and goes in following stages.

1) POC - proof of concept. It does 90% of things, some parts are ugly and messy but validates a hypothesis. The unknown unknowns are discovered. I want to stage this and get this in front of some alpha internal users as soon as I can. First pass reviewers give a on the plan of attack. Lots of sub TODO’s are listed in PR. The goal is to discover edge cases and unknown unknowns.

2) Simple - Go through PR and refactor any existing / new code so it’s readable and DRY. If reviewers don’t understand the “why” of some code, a comment is left. Now 90% of scenarios are covered, probably some edge cases may not work but the edge cases are known. The code is simple and at right layer of abstraction.

3) Correct, Testable - Edge cases are covered, tests are written, internal users have validated that the feature is working as expected.

4) Polish - if it’s slow, then slow internals are swapped out for fast parts. Tests would mostly work as is. Same with UI, css fixes to make it elegant and pretty.

Sometimes the process is a day, sometimes it’s a week.

Re: Simple, correct, fast: in that order

#275

Post by mockingbirdy »

aidenn0 wrote: post #168
kibwen wrote: post #144

Earlier quoted context omitted.

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"

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

Re: Simple, correct, fast: in that order

#276

Post by abakus »

Apparently everybody knows "correctness" comes first. But that is the whole point of this article: It argues that complexity will reduce correctness, and thus simple should come first.

Please NOTE that I am not saying that I agree or disagree with this article.

Re: Simple, correct, fast: in that order

#277

Post by tshannon »

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 was going to say the same.

The conclusion I came to personally was always

Accuracy > Maintainability > Performance

in that order

Re: Simple, correct, fast: in that order

#278

Post by gwbas1c »

kungtotte wrote: post #270
gwbas1c wrote: post #245

That mantra, taken blindly, leads to software that won't scale under realistic circumstances. I once worked on a project that failed because the lead programmers did not want to learn how to use a database. They insisted on using an ORM incorrectly, and almost all of their code needed to be rewritten in order to handle a typical anticipated load. Granted, the entire codebase was full of "simple" for each loops, but t…

There's a difference between simple and simplistic, and there's absolutely a value in keeping things simple instead of complex. So much so that I think it's reasonable to state categorically that if there is a simple solution that works it's always better than the complex solution. Not using a database when the solution calls for one clearly violates the "works" principle. And obviously, using a tool incorrectly (the…

It's like some people take "optimize last" to the extreme. A project needs to handle anticipated load at the beginning.

For example, if a web application needs to handle 20,000 requests an hour, it's okay if early versions take 10-15 seconds to respond under unusually high load. The optimization phase can bring that down to something more manageable.

Some people take the "optimize last" so far that they ignore their basic scalability requirements; or just assume there are no scalability requirements. That's when a more senior dev needs to step in and demand basic scalability in the design.

Re: Simple, correct, fast: in that order

#279

Post by smaddox »

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…

And since "fast enough" is a part of "correct", the order should really be "correct, fast enough, simple".

Re: Simple, correct, fast: in that order

#280

Post by sethrin »

kungtotte wrote: post #272
AstralStorm wrote: post #242

Earlier quoted context omitted.

4) After thinking how to get beat bang for buck when optimizing. Profilers don't always pinpoint the culprit.

I have a hard time seeing how profilers don't at least point you in the right direction. Or are we using different definitions of the word? They tell you how much time is spent in any given section of your program. If 80% of the time is spent in 20% of the code, it's usually a safe bet that's where you should start looking!

Profilers have limitations like anything else, and it's possible to be pointing the flashlight in the wrong place. I probably wouldn't include that as a list item.

By the by, is there more than one kungtotte on the Internet? It took me a minute to think why that name was so familiar, but then I remembered watching a few hundred Beaglerush videos.

Post reply on HN