Live data from Hacker News

Simple, correct, fast: in that order

drewdevault.com

11–20 of 349 posts

Re: Simple, correct, fast: in that order

#11

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.

Agreed. Software that does what it's supposed to is better than software that is simple (or fast), but buggy.

Re: Simple, correct, fast: in that order

#12

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.

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.

Re: Simple, correct, fast: in that order

#13

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.

Every piece of software that has bugs could be considered not correct, which is the vast majority of it.

Re: Simple, correct, fast: in that order

#14

This title is misleading. The post actually says that the reason "simple" comes first is because without it you can't have "correct" (nor "fast", not that that matters so much). So he's not saying simple is most _important_, just that it comes first chronologically, and has the other two as consequences.

e.g. Gall's law

> A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Re: Simple, correct, fast: in that order

#15
and funnily enough, writing simple code is the hardest part to learn, because you can't measure it until it falls down on you

now that I think about it, that would be a good exercise for programming students. after writing a program that does a certain task, make the student rewrite it to be simpler/easier to understand/maintain. then take a look at the best solutions in the class.

Re: Simple, correct, fast: in that order

#16
post #13

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.

Every piece of software that has bugs could be considered not correct, which is the vast majority of it.

Depends on the definition of bug.

Re: Simple, correct, fast: in that order

#17
post #6

The simplest code is an empty file. And yet, we live in a world with complex software. There are tradeoffs, but this article doesn't help you make them.

> 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.

Re: Simple, correct, fast: in that order

#18

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.

All general rules like this are terrible if you apply then blindly, but can still be useful if you apply them loosely.

In your example, I would take simple to mean "only use UTC". As soon as you need timezones I would say you've moved into correctness territory and need to do them all properly (you would use a good library, of course).

Re: Simple, correct, fast: in that order

#19

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 point is that it should be as simple as possible to solve the problem but no simpler.

Re: Simple, correct, fast: in that order

#20

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.

Those three properties are very highly related.

Personally I found the biggest improvement to my own software came from maintaining the same system that I wrote for 4+ years.

If I came back to a part and didn't understand it more or less immediately, then it was time to refactor it. I wrote the code I should understand what it is doing. No excuses that someone else had written bad code.

Post reply on HN