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

211–220 of 349 posts

Re: Simple, correct, fast: in that order

#211

Post by Sir_Cmpwn »

jasode wrote: post #193
Sir_Cmpwn wrote: post #135

Earlier quoted context omitted.

You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

>a simple way, [...] and running a script to update future dates I've commented previously that it's not a good idea to change the rows of UTC times in the database.[1] Designing "system correctness" to depend on on the reliability of a correctly written SQL statements completing atomic transactions for millions of rows is not a good idea. In addition to batch db updates of UTC being extremely fragile, it's also not…

The event's time has changed, though. The local representation of when it will occur has not changed, but if you set a timer today and they change their timezone tomorrow, the timer will expire at the wrong time.

We should store the actual time of an event and update it when the scheduled time changes.

Re: Simple, correct, fast: in that order

#212

Post by tumdum_ »

hawkice wrote: post #113
tumdum_ wrote: post #17

Earlier quoted context omitted.

> this article doesn't help you make them Sure it does. It clearly states that sometimes new features or performance optimisations have to be sacrificed to keep the software simple.

That's like saying, sometimes apples are so expensive you can't buy them. Perhaps surprising, if you haven't thought of it, but it is an obviously true statement about all tradeoffs. Sometimes you shouldn't make them. Still doesn't help you figure out when you should.

Maybe it’s obvious to you but at least in my experience lots of devs when confronted with feature request rarely consider if said feature should be implemented. Most of the time they only think how it could be implemented.

Re: Simple, correct, fast: in that order

#213

Post by rhapsodic »

Sir_Cmpwn wrote: post #135
jasode wrote: post #122

Earlier quoted context omitted.

>", you should instead store time in UTC everywhere It is not possible to store UTC unambiguously on the db server for all future local wall-clock times. (Previous comment about the erroneous assumption of "UTC everywhere" being a "simple solution".[1]) Therefore, redefining "correct" to be "store UTC everywhere" achieves the exact opposite: an incorrect and buggy program. That's because the "universal" in Universal…

You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

>You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.

Seriously? That, in your opinion, is simpler?

Re: Simple, correct, fast: in that order

#214

Post by kibwen »

jpfr wrote: post #209
kibwen wrote: post #186

Earlier quoted context omitted.

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

We reached the maximum thread depth. >> Simplicity is a much better goal for the day-to-day work. Because it can be tracked, measured and evaluated for every individual change. >How does one purport to measure simplicity? There's 40 years of research into that. And loads of tools to support dev teams. You can start here: https://en.wikipedia.org/wiki/Cyclomatic_complexity Also related are costing models: https://en.w…

We also have 40 years of research into improving program correctness, e.g. static analysis, test suites (unit, integration, etc.), fuzzing/mutation testing, and the benefits of code review. The idea that simplicity (which I'm pretty sure that nobody in here is using to specifically mean "the lack of cyclomatic complexity") can be measurably improved but that correctness cannot is incorrect.

Re: Simple, correct, fast: in that order

#215

Post by bmurphy1976 »

ythn wrote: post #114
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. Not always. Have you ever used a SNES emulator? There is one emulator that is more correct than all others combined - it's called BSNES and it's the most true to the original SNES hardware of all the available emulators. Yet it is horrifically memory/cpu hungry - that correctness comes at a huge cost. So no, correctness does not always come first, especially if you value other things like u…

Your definition of correctness is wrong in this case. If the purpose is to emulate the hardware as accurately as possible, BSNES wins. If the purpose is to make as many games as possible enjoyable for as many people as possible on the lowest common denominator hardware available today, BSNES loses.

There's no clinical definition of correctness here. Intent matters.

Re: Simple, correct, fast: in that order

#216

Post by __mifflin »

susam wrote: post #208

My approach towards software development has been pretty similar except that my order of priorities is a little different. I prefer: Correct, simple, fast, in that order. In other words: - First get a correct solution working that solves the problem correctly for typical as well as corner cases, hopefully with good test coverage for both typical and corner cases. - Then improve the solution to make it simpler while p…

I like this approach, and it's usually the one I follow.

When I'm first building out a feature, I need to make sure that it actually works (i.e. is correct). Once that's out of the way, I'll have a good idea of what it takes to make that functionality actually work correctly, and can begin making it simpler while preserving correctness.

Simplicity is easy if correctness is not a constraint.

Re: Simple, correct, fast: in that order

#217

Post by kibwen »

guiambros wrote: post #203
kibwen wrote: post #186

Earlier quoted context omitted.

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

> ...reinforcing that correctness is more important than simplicity It's the other way around. Correctness is obviously the goal (and likely performance too, depending on your use case), but the way to achieve it is through simplicity. So simplicity should be prioritized - as it allows you to ensure correctness.

I'm glad that we can agree that correctness is the goal, though I still take umbrage to the blog post's title, thesis, and conclusion. :P

Re: Simple, correct, fast: in that order

#218

Post by lubujackson »

kibwen wrote: post #149
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. Seconded. I'm highly confused at how many upvotes the OP has gotten in such a short time despite appearing to say that implementation details matter more than program output. A beautiful machine that doesn't work is, at best, a statue. I'm all for the existence of pretty things that do not need to demo…

To defend the idea, I think it starts with the assumption that software is often a moving target so "correctness" is at best a temporary state. If you had to use a codebase at any point of time you would obviously want the correct one, but if you look at the lifespan of software it would be better to have the simpler code. Simpler is (usually) easier to fix, easier to extend and easier to learn.

I think the author made this a little inflammatory to get people to think about it in these terms.

Re: Simple, correct, fast: in that order

#219

Post by adrianmonk »

DannyB2 wrote: post #38
martingxx wrote: post #12

Earlier quoted context omitted.

Correctness (and any other kind of change in behaviour) is easier to achieve if things are simple. Changes are not necessarily easy or even possible to make safely if things are correct but not simple. "Simple" is a proxy for "can be changed safely" and so IMO is the most important quality to have.

I think you do whatever it takes to achieve correctness. If simplicity helps achieve correctness, then great. But correctness is not always simple. Most people think there is a leap year every four years. They are wrong.

One nuance is that some parts of correctness may be negotiable.

If I'm writing a file backup program, it absolutely must back up all the files without leaving any out or corrupting the data.

But let's say it has a feature that prints progress indicator percentages on the command line, ranging from 0% to 100%. Maybe under certain circumstances (like files added to a directory after the backup starts), it prints 102%. It's not what I had in mind, nor is it something I'd call correct. But if fixing it complicates the code a lot, maybe leaving it that way is the better choice.

(This is a bit of a contrived example because you could just clip the value at 100, but you get the idea.)

Post reply on HN