Simple, correct, fast: in that order • Hacker News Board

Re: Simple, correct, fast: in that order

#241

Post by coryfklein » Mon, Jul 09, 2018, 5:18 PM UTC

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.

I don't think what you're saying is in conflict with the OP:

> The complex problem comes later, and it’ll be better served by the composition of simple solutions than with the application of a complex solution.

Complicated problem domains can be made into simple ones by breaking them down into their constituent components. You can solve time zones by having 5000 Rube-Goldberg-esque lines of if/else-if statements, or you can organize the system into simple components that build on each other.

At any given component or level the problems are clear, simple, and identifiable, and the complexity arises as the components join to form abstractions upon which higher levels operate.

Re: Simple, correct, fast: in that order

#242

Post by AstralStorm » Mon, Jul 09, 2018, 5:19 PM UTC

sethrin wrote: post #188

taneq wrote: post #78

Earlier quoted context omitted.

Yep, this is the version I heard. I think the distinction between "make it work" and "make it work right" is important, though - where "work" means "solve the problem", and "work right" means "solve the problem in a robust and reliable manner." If your software doesn't solve the problem, it's useless, no matter how correct or fast it is. Once it solves the problem, then you can work on making it bug free and elegant.…

3) Profile before optimization.

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

Re: Simple, correct, fast: in that order

#243

Post by AstralStorm » Mon, Jul 09, 2018, 5:24 PM UTC

asragab wrote: post #199

I think to those that are asserting that correctness comes first are somewhat missing the point. One, a simple solution is still a solution, that is if your code doesn't solve the problem, you can't stop. I think the author is suggesting that truly _correct_ code (code that produces the correct output under all circumstances) is only attainable iteratively, and if your code is not simple (and let's also remember here…

In practice of many years, I haven't found iterative approach to produce either simple or easily maintainable code. If tends to grow rings instead. Each layer is relatively simple but altogether neither it is performant nor simple.

The simple code of present was almost always written by someone who understands the problem domain really well in one or two tries.

Re: Simple, correct, fast: in that order

#244

Post by amorphid » Mon, Jul 09, 2018, 5:27 PM UTC

For any non-trivial program, I usually end up with: working jank, maintainable jank, fast jank. If I can write something that works AND isn't a ball of mud, I'm pretty happy.

Re: Simple, correct, fast: in that order

#245

Post by gwbas1c » Mon, Jul 09, 2018, 5:27 PM UTC

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 the reality is that if they had started by writing correct database queries, the project would have never failed.

Thus I say, optimize for your budget at the beginning of the project. You should pick design patterns that handle anticipated load. Full optimization can come in later, but if your project can't handle anticipated load at the beginning, then you are misinterpreting what this "simple, correct, fast" mantra really means.

Re: Simple, correct, fast: in that order

#246

Post by zzzeek » Mon, Jul 09, 2018, 5:30 PM UTC

How do measure "simple"? Is PostgreSQL "simple"? If not, is PG not considered to be "correct" or "fast"? Seems like it does a pretty good job to me and no, PostgreSQL isn't exactly "simple".

Re: Simple, correct, fast: in that order

#247

Post by bennofs » Mon, Jul 09, 2018, 5:30 PM UTC

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…

I would argue that this was not "simple". For me, simple means that it is easy to understand what is going on. If your using an ORM wrong, then you're not understanding what is going on under the hood so it is not simple.

If you really write simple code, you should also be aware of the shortcomings of the simple approach.

Re: Simple, correct, fast: in that order

#248

Post by tacon » Mon, Jul 09, 2018, 5:30 PM UTC

Is the software engineering profession doomed to lose its memory every generation? The premise of this post is ridiculous:

>The single most important quality in a piece of software is simplicity.

How panglossian, imagining the best of all possible worlds. Well, the world is intrinsically complex, as Fred Brooks explained in his No Silver Bullet essay from 1986[0].

"The complexity of software is an essential property, not an accidental one."

Sure, there is accidental complexity in most software problems, that can be tackled with skill and experience, and maybe reduced to zero. But then you are left with the essential complexity of the world. And you are done reducing the complexity; you can only manage it from then on. The world is very, very complex and it is a pipe dream to imagine that we can eliminate its complexity just by some bold engineering.

[0] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

Re: Simple, correct, fast: in that order

#249

Post by ythn » Mon, Jul 09, 2018, 5:34 PM UTC

kibwen wrote: post #186

jpfr wrote: post #179

Earlier quoted context omitted.

Correctness is achieved by simplicity.

> Correctness is achieved by simplicity. That's... literally what I just said? "Achieving correctness is the whole point of making things simple, after all."

Yes but I think OP is saying that, paradoxically, prioritizing correctness over simplicity actually makes correctness more elusive than if simplicity were prioritized.

Re: Simple, correct, fast: in that order

#250

Post by amatheus » Mon, Jul 09, 2018, 5:42 PM UTC

It seems to me like what the author proposes fits with TDD: start building the simplest case by way of a unit test, implement it in the simplest way, and keep going that way; while the “correct first” approach many are saying should be used feels more like having a problem, really thinking about how it should be solved and then solve it all at once.

Now, while I think some small and contained problems may be solved the second way, I think most complex problems of the kind we solve as programmers will be best solved the first way.