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

Re: Simple, correct, fast: in that order

#21

Post by aunty_helen » Mon, Jul 09, 2018, 2:04 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.

But would it be better to account for non-end of year leap second additions vs something simplier that just ignores them but is wrong once every... decade?

Re: Simple, correct, fast: in that order

#22

Post by ythn » Mon, Jul 09, 2018, 2:04 PM UTC

I subscribe to this philosophy, but unfortunately simplicity is surprisingly difficult for most software devs. It's because if you don't have the tool in your toolbox, you won't even know it can be simplified.

I once did a code review for a function that parsed some Linux file for Ethernet stats. It was incredibly convoluted with tons of substring finding and indexing. I told the author to simplify it and he declared he already had and it was as simple as it could get. I then showed him of the existence of regex and his mind was blown.

Re: Simple, correct, fast: in that order

#23

Post by collyw » Mon, Jul 09, 2018, 2:05 PM UTC

pieterr wrote: post #8

I prefer: “the strategy is definitely: first make it work, then make it right, and, finally, make it fast”. http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

This is better. If you can make it work while keeping it simple the other two will follow more naturally.

Re: Simple, correct, fast: in that order

#24

Post by m90 » Mon, Jul 09, 2018, 2:05 PM UTC

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.

I'm getting ERR_SSL_VERSION_OR_CIPHER_MISMATCH (no content displayed) on latest Chrome / Linux when trying to access the link (which force redirects me to use https). In case it's your site, you might want to know / fix.

Re: Simple, correct, fast: in that order

#25

Post by perl4ever » Mon, Jul 09, 2018, 2:07 PM UTC

rhapsodic wrote: post #3

> The reason is straightforward: if your > solution is not simple, it will not be > correct or fast. A very hand-wavy statement, and not always true.

"Everything should be made as simple as possible, but not simpler"

Re: Simple, correct, fast: in that order

#26

Post by lopatin » Mon, Jul 09, 2018, 2:07 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 think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones.

Re: Simple, correct, fast: in that order

#27

Post by tomp » Mon, Jul 09, 2018, 2:08 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.

Indeed. During my visit to India in February this year, I didn't even realize they were at a half-hour time-zone offset, all thanks to the miracle of modern technology (and hardworking people maintaining it).

Re: Simple, correct, fast: in that order

#28

Post by imron » Mon, Jul 09, 2018, 2:08 PM UTC

aunty_helen wrote: post #21

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.

But would it be better to account for non-end of year leap second additions vs something simplier that just ignores them but is wrong once every... decade?

Depends on the software.

Re: Simple, correct, fast: in that order

#29

Post by purpleidea » Mon, Jul 09, 2018, 2:09 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.

Came here to say the same thing. OP doesn't know what he's talking about.

Re: Simple, correct, fast: in that order

#30

Post by Jtsummers » Mon, Jul 09, 2018, 2:11 PM UTC

ythn wrote: post #22

I subscribe to this philosophy, but unfortunately simplicity is surprisingly difficult for most software devs. It's because if you don't have the tool in your toolbox, you won't even know it can be simplified. I once did a code review for a function that parsed some Linux file for Ethernet stats. It was incredibly convoluted with tons of substring finding and indexing. I told the author to simplify it and he declared…

Exactly. And this is a major reason to always be on the lookout for new things to learn.

I had a similar experience (but earlier in his coding process) and managed to change what was about to be a months long effort of adding epicycles and epicycles to code into a one week task. I have most of my library at work and constantly speak of design and theory concepts with the younger folks. Based on more recent code it's paying off.