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

Re: Simple, correct, fast: in that order

#91

Post by quadcore » Mon, Jul 09, 2018, 2:42 PM UTC

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…

How do you know it was more complex because from what I read it was slower which is different.

Re: Simple, correct, fast: in that order

#92

Post by Dylan16807 » Mon, Jul 09, 2018, 2:42 PM UTC

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…

> 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 you edit the software, which helps you make it correct sooner. Simplicity and correctness go very well together.

Re: Simple, correct, fast: in that order

#93

Post by jstimpfle » Mon, Jul 09, 2018, 2:42 PM UTC

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.

Maybe the test cases / requirements are "wrong"? I think simplicity is the ultimate test that you found a good problem!

Re: Simple, correct, fast: in that order

#94

Post by Sir_Cmpwn » Mon, Jul 09, 2018, 2:43 PM UTC

rhapsodic wrote: post #76

Sir_Cmpwn wrote: post #55

Earlier quoted context omitted.

If you cannot achieve correct without simple, redefine correct.

> If you cannot achieve correct without simple, redefine correct. More hand-waving.

I disagree. I just can't get more specific without specific cases to examine. Like others have pointed out, take the matter of timezones: if "correct" is defined as "handling timezones", you should instead store time in UTC everywhere and redefine "correct" to be "convert times to local time when displayed and back again when input", which can be accomplished with much smaller, simpler, and focused tools.

Re: Simple, correct, fast: in that order

#95

Post by JoeAltmaier » Mon, Jul 09, 2018, 2:43 PM UTC

Sir_Cmpwn wrote: post #55

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.

If you cannot achieve correct without simple, redefine correct.

Some problems are just hard and complicated. You can try to make code that dissects it into lots of simpler pieces, but then they have to be put together in a complicated way. Someplace in the code there will be some point of irreducible complexity. In my experience.

Re: Simple, correct, fast: in that order

#96

Post by majewsky » Mon, Jul 09, 2018, 2:43 PM UTC

taeric wrote: post #62

s3m4j wrote: post #54

Earlier quoted context omitted.

In my experience, it's been easier to push UTC time all the way from the db to the user javascript and operate on time then, than trying to manipulate time before sending to the user. YMMV, and it's only web dev.

This works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.

For example, a task that occurs "daily at 15:00" does not always happen every 24 hours. When DST comes into effect, the interval shortens to 23 hours once.

Re: Simple, correct, fast: in that order

#97

Post by mike_ivanov » Mon, Jul 09, 2018, 2:44 PM UTC

The simplest possible program that is not correct is no program at all, so why bother?

Re: Simple, correct, fast: in that order

#98

Post by quadcore » Mon, Jul 09, 2018, 2:44 PM UTC

I've found that what keeps more programmers from simplicity is that people like things to be in order. Like their desks or their living room. I've found that seemingly messy code that are actually simple perform better than complex supposedly in-order code.

Re: Simple, correct, fast: in that order

#99

Post by jstimpfle » Mon, Jul 09, 2018, 2:45 PM UTC

rhapsodic wrote: post #76

Sir_Cmpwn wrote: post #55

Earlier quoted context omitted.

If you cannot achieve correct without simple, redefine correct.

> If you cannot achieve correct without simple, redefine correct. More hand-waving.

"redefine correct" = "find a better version of the problem". Software development starts with requirements analysis.

Re: Simple, correct, fast: in that order

#100

Post by dwc » Mon, Jul 09, 2018, 2:46 PM UTC

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…

Yes, correctness absolutely comes first.

One way to achieve greater simplicity is to negotiate for fewer/simpler requirements for the first revision. There's often a core set of functionality that can be implemented correctly in a simpler way, and that gets the work done. Once that's in place it's interesting to see how often people lose interest in what were "hard" requirements before. It's also common that new asks have little to no resemblance to those unimplemented features, and are instead things that they found out they needed after using the new system.