Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I always thought correctness begins when the result of your work does what it's supposed to do.

Maybe it's supposed to move from A to B, maybe it should do it in under x seconds, maybe it should go via Y, maybe it has to be easily understood by a 6 years old, etc.

But I can't really imagine something that has simplicity as the only requirement ("nothing" is the simplest thing so that requirement would always be met with no action). So as long as the other requirements are met simplicity is usually the nice to have "add-on". And you can have correct and simple, or correct and complex. But correct (does the job) trumps simple. And the world is surrounded by examples that prove this point.

I think the author meant "simple should be part of good design" but couldn't properly convey the message. He focused on making the message simple and ignored the fact that it's not correct.



I’ve noticed a pattern where the simplest solution DOES accomplish the goal, but isn’t what a user might consider the “shortest path”. How do you count a workaround where it technically can accomplish the end result, but requires a minor annoyance? What about a major annoyance?

What about a process so painful nobody has even thought of it?


It's nigh impossible to solve any complex issue with the "simplest solution" from the first try. This means that when you're faced with a complex issue you will postpone the fix because it's not the simplest.

And you never know if it can be done in an even simpler fashion later.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: