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

31–40 of 349 posts

Re: Simple, correct, fast: in that order

#31

Post by jasonkester »

m90 wrote: post #24
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.

Thanks, Cloudflare. I noticed after posting that that blog is still running without SSL, so I did the quickest thing that would work and moved it over to Cloudflare and their Fast SSL product.

Evidently, they're happy to start auto-forwarding http traffic over to https before finishing the part where https works.

I've flipped it back off for the time being. Thanks for the heads up.

Re: Simple, correct, fast: in that order

#32

Post by michaelcampbell »

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.

The old yarn I'd heard for years is close to this.

Make it work. Make it work right. Make it work fast.

In that order.

Now it could be argued that "work right" can be read as "make it (work right)", or "(make it work) right", or both, but I think the point of this saying is that the "fast" part should always come later.

Re: Simple, correct, fast: in that order

#33

Post by eggbrain »

One of the lessons I've learned (that this article echos upon) is that you should _always_ factor the "long term cost" of adding a feature.

When I first started building TrueJob (job board software), I'd add in all these really cool features that made my app -- and at the time, they felt really useful. But over time, people weren't using them, so I built more features.

But then the old features I had built broke, so I had to fix them. And then they lagged behind the quality of other features I had written them, so I had to update them. And after doing this 5-10 times (as the software evolved and I dramatically increased the complexity of my application), these features that no one used really were painful to keep coming back to, but now enough loud users were using them that I couldn't remove them.

It made me really value the projects where we polished and did just a very few things, but did those very very well -- it lead to higher customer satisfaction, and less pain in the long run for us.

Re: Simple, correct, fast: in that order

#35

Post by grok2 »

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.

So long as the software will only be shipped after all three stages, it's a useful metric to go by, I guess. It prevents you getting overwhelmed by the myriad amount of decision-making that writing software is. And also, so long as you accept the fact that you will need minor or major redesigns by the time you get to the "fast" version that is production ready.

Re: Simple, correct, fast: in that order

#36

Post by bluetomcat »

Simple means that there is less to go wrong, but not necessarily correctness. A seemingly simple implementation can also hide a lot of behavioural complexity behind abstraction layers. The program might not crash, but it might not behave properly either.

Re: Simple, correct, fast: in that order

#37

Post by neogodless »

Think about it in terms of each choice you make.

I have a simple solution and a complex solution. Does the simple solution meet the requirement(s) before me? If so, I prefer it. Let's move on to the next requirement and consider my options again.

The alternative might be to look at your requirements, but choose a complex solution (over a simple one) because you think it might meet other requirements, either ones that have not yet been identified or ones you think are likely to happen in the future.

Are there times that the more complex solution wins? Probably. Consider you want to write a blog. You know that you can create an HTML (text) file and slap it on a web server and your blog has started. But if you've done this before, you might also know that you can throw WordPress on your server for a little more up front pain. You know you want comments and word clouds and date/time stamps and navigation. So you choose the complex solution. (You also know that you know face potential security implications, upgrades, dealing with users causing trouble with comments, having the PHP/MySQL infrastructure/hosting requirements...) Maybe you just wanted to dump your thoughts to the internet. Maybe the text file approach was better...

It may just be another way to say "avoid gold-plating your software."

Re: Simple, correct, fast: in that order

#38

Post by DannyB2 »

martingxx wrote: post #12
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.

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.

Re: Simple, correct, fast: in that order

#39

Post by betacat »

meheleventyone wrote: post #19
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.

The point is that it should be as simple as possible to solve the problem but no simpler.

This generic expression indicates why "correct" comes first. "Simple" has it as a dependency. ;)

Re: Simple, correct, fast: in that order

#40

Post by slx26 »

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.

as I understand it, both simplicity and correctitude are requirements for most programs, but imo the article talks about the design, the writing process, where you should focus first on writing a program that's not more complex than it needs to be, because you are likely compromising the other parts too. this doesn't mean incorrect code is acceptable.

in any case, I think it's also worth mentioning that the article is probably talking about "incorrect" as in "accidental bugs", not as in "purposely ignoring the complexity of the problem". with the idea of preventing over-engineering rather than dismissing the specifications of a valid solution

Post reply on HN