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

81–90 of 349 posts

Re: Simple, correct, fast: in that order

#81

Post by jstimpfle »

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…

There's a sweet spot in the neighbourhood of well-defined problems and low complexity, that sings phrases like Before even trying to implement it I know it can be done right, or Even though it can't be done 100% right, that's just the nature of the problem domain. Give the users a good enough solution that they can understand, so they can use it in the way _they_ need.

Re: Simple, correct, fast: in that order

#83

Post by rdiddly »

Been working on some legacy code that is so convoluted, you sometimes can't even tell if it's correct, without starting to rewrite. Once you grok what it's doing, there's almost always a simpler & more direct way. This in turn usually makes it faster, AND sometimes more correct. It's pretty gratifying, though there are many SMH moments.

Re: Simple, correct, fast: in that order

#84

Post by kyleperik »

agentultra wrote: post #77

I think this is lacking a definition of simple. And where in the problem space do we desire simplicity? Simple in the implementation (and conversely complex in the interface? ie: C-style libraries?) Or complex in the implementation but simple in the interface? (ie: Haskell/FP style libraries?) My definition of simple software is software that I can validate the correctness of using only equational reasoning and the m…

Sounds like you're over complicating simplicity

Re: Simple, correct, fast: in that order

#85

Post by karma_fountain »

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…

Seen this several times when someone refactors. The code is much simpler and easier to read, but does not actually work for several important test cases anymore.

I've never thought of simplicity adding upfront cost. That's probably true, but also true that it pays dividends later on in the project.

Re: Simple, correct, fast: in that order

#86

Post by cbsmith »

michaelcampbell wrote: post #32
SamuelAdams wrote: post #2

I would argue that correct is more important than simple. Consider timezones: it's simpler to pretend there's 24 time zones, one for each hour. But the correct assertion is there's 37 time zones (as of this writing). So, the simple solution results in a third of your potential user base having issues. Other issues to pick: accessibility, cross-browser compatibility, legacy device compatibility... the list goes on.

The old yarn I'd heard for years is close to this. Make it work. Make it work right. Make it work fast. In that order. Now it could be argued that "work right" can be read as "make it (work right)", or "(make it work) right", or both, but I think the point of this saying is that the "fast" part should always come later.

The make it work fast portion isn't controversial. Premature optimization and all that...

The "make it work" implies a level of correctness & performance that is acceptable, which is why any subsequent steps are after thoughts.

Re: Simple, correct, fast: in that order

#87

Post by thedirt0115 »

agentultra wrote: post #77

I think this is lacking a definition of simple. And where in the problem space do we desire simplicity? Simple in the implementation (and conversely complex in the interface? ie: C-style libraries?) Or complex in the implementation but simple in the interface? (ie: Haskell/FP style libraries?) My definition of simple software is software that I can validate the correctness of using only equational reasoning and the m…

+1 to acknowledging that when it comes to software, "simplicity" does not have one exact quantitative meaning we all agree on -- for now, simplicity is still in the eye of the beholder in my opinion.

Re: Simple, correct, fast: in that order

#88

Post by bigjimmyk3 »

DannyB2 wrote: post #51
d__k wrote: post #34

Some other formulations: - Occam's razor https://en.wikipedia.org/wiki/Occam%27s_razor - "Simplicity is the ultimate sophistication" (Leonardo da Vinci) - "Less is more" (Mies Van Der Rohe) - "Make everything as simple as possible, but not simpler" (Albert Einstein)

All four of those are great! But if they are wrong, then it is still wrong no matter how simple. Like saying leap years occur every four years. Simple!

I think I read the OP's assertion in relation to your counterpoint like this: when thinking through the problem, your initial iteration of work is allowed to say exactly that: a leap year occurs every 4 years. However, you should do so via a semi-stubbed function (isLeapYear) as mentioned previously. I am imagining that the specifics of when a leap year occurs are not critical to your solution, only that you know when they happen. Thus, you avoid spending too much time on a detail that's eventually important, but not critical for proving your first hypothesis. In the "correct" stage you come back and improve the isLeapYear function to return correct results.

Part of attaining wizard status is not learning how to hold more of the program in your head, but instead learning how to hold _less_. This seems like an excellent step in that direction.

Re: Simple, correct, fast: in that order

#89

Post by DannyB2 »

karma_fountain wrote: post #85
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…

Seen this several times when someone refactors. The code is much simpler and easier to read, but does not actually work for several important test cases anymore. I've never thought of simplicity adding upfront cost. That's probably true, but also true that it pays dividends later on in the project.

If it no longer works then I don't consider that to be "refactoring" but "rewriting".

I think of refactoring as a series of SIMPLE transformations that clearly do not have any effect on the correctness (or incorrectness) of the code. That is, there is no possible change in behavior.

And think of the word "factoring" as in high school algebra. or rather "factoring out" something.

I have a dozen examples of this calculation. How about let's refactor it into a function, and replace all the instances with a function call?

Re: Simple, correct, fast: in that order

#90

Post by d__k »

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. Simplicity is highly desirable, adds additional cost, but always comes after correctness.

It is true mainly for one-time contracts where you actually might not care about simplicity at all. Enough is enough.

However, in the case of iterative projects keeping complexity under control has much higher priority including top priority for very big projects. Complexity and high entropy can easily kill everything.

Post reply on HN