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

251–260 of 349 posts

Re: Simple, correct, fast: in that order

#251

Post by wellpast »

tacon wrote: post #248

Is the software engineering profession doomed to lose its memory every generation? The premise of this post is ridiculous: >The single most important quality in a piece of software is simplicity. How panglossian, imagining the best of all possible worlds. Well, the world is intrinsically complex, as Fred Brooks explained in his No Silver Bullet essay from 1986[0]. "The complexity of software is an essential property,…

Anyone who has spent any time developing anything but a tiny software system knows that the biggest impediment to productivity (feature delivery, bug fixing, etc) is the complexity of the system at hand.

In a sense, this post is simply stating the obvious.

The biggest differentiator of skilled software practitioners is the ability to construct simple systems.

To call this claim panglossian or meaningless is to hold the philistinic line that this skill set doesn't matter, that any complex system is effectively the same as any ol' simple one -- don't worry about cultivating the skill, it doesn't matter anyway...

But simplicity is the single most important thing that matters in any maintaining system other than one-off scripts, hack jobs, etc. -- It's absolute torture to collaborate on a software project with anyone who rejects this premise.

Re: Simple, correct, fast: in that order

#252

Post by ben509 »

bennofs wrote: post #247
gwbas1c wrote: post #245

That mantra, taken blindly, leads to software that won't scale under realistic circumstances. I once worked on a project that failed because the lead programmers did not want to learn how to use a database. They insisted on using an ORM incorrectly, and almost all of their code needed to be rewritten in order to handle a typical anticipated load. Granted, the entire codebase was full of "simple" for each loops, but t…

I would argue that this was not "simple". For me, simple means that it is easy to understand what is going on. If your using an ORM wrong, then you're not understanding what is going on under the hood so it is not simple. If you really write simple code, you should also be aware of the shortcomings of the simple approach.

A DBMS is inherently less simple than for loops, that's entirely true.

But that's the class of problem they were trying to solve. And a DBMS represents vast amounts of energy put into trying to solve that class of problem.

So, the problem was a complex one, but one that had many aspects of it already solved, and rather than building on a good solution (the DBMS) they chose to try and reinvent queries.

> you should also be aware of the shortcomings of the simple approach

Yup, you really can't refuse to learn how databases work. Unfortunately, they didn't know what they didn't know.

Re: Simple, correct, fast: in that order

#253

Post by ben509 »

whack wrote: post #140
zurn wrote: post #57

Earlier quoted context omitted.

A counter-anecdote: The features you listed started shipping (from Intel & MIPS) in microprocessors in 1996, 22 years ago. Intel's out-of-order Pentium Pro was beaten by the in-order DEC 21164 the same year. Also, there's the case of Intel losing to in-order ARMs in mobile. First with XScale, and later on with the in-order Atoms. ( https://appleinsider.com/articles/15/01/19/how-intel-lost-th... )

Sure, specific optimizations in specific markets may not be worth the cost they incur. Or they may not be valuable enough to overcome other weaknesses in the project. And yet, if someone tried to sell a server CPU today that was not pipelined, not OOO, and didn't have branch prediction, it would absolutely tank in the marketplace. I never said that performance optimizations should always be implemented. Just that per…

> And yet, if someone tried to sell a server CPU today that was not pipelined, not OOO, and didn't have branch prediction, it would absolutely tank in the marketplace.

You could sell it as a niche product for high security applications, since OOO execution is a nasty side-channel.

Re: Simple, correct, fast: in that order

#255

Post by a1369209993 »

kibwen wrote: post #186
jpfr wrote: post #179

Earlier quoted context omitted.

Correctness is achieved by simplicity.

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

By that logic, "fast" goes before "correct"; you can't print the answer quickly if you don't have the answer, after all.

> if your solution is not simple, it will not be correct or fast.

The point of the article is that "simple" is a prerequisite of "correct" (and "fast").

Re: Simple, correct, fast: in that order

#256

Post by wellpast »

jsdalton wrote: post #239

I often repurpose a famous quote from Mark Twain (about letter writing) for the topic of simplicity: > I didn't have time to write a simple program, so I wrote a complicated program instead. This is in my experience more than just a clever turn of phrase: the vast majority of software projects (or features etc.) move from _simplistic_ to complicated, and rarely from there toward simplicity. The end result is exactly…

I've found that, unlike Mark Twain's profession of writing and art, in which each new work is attempting to push the bounds of thought and expression, constructing simple software is something that you can actually get better at over time, and with focussed practice. I hate to break this to us, but what we software developers do over and over again is not as novel and groundbreaking as, say, what a Mark Twain is doing with each work of art he produces.

This is certainly true for me after 20 years of focussed practice. In fact, I have to go out of my way now to introduce coupling--it takes time for me to do the wrong thing. So when I hear someone say "I don't have time to make it simple / decouple everything / design it correctly", what I really hear is "I don't have the skill set" and, often, "I don't want to do the hard work and patience it takes to require the skill set." It's a philistinic cop out, really.

Re: Simple, correct, fast: in that order

#257

Post by tacon »

wellpast wrote: post #251
tacon wrote: post #248

Is the software engineering profession doomed to lose its memory every generation? The premise of this post is ridiculous: >The single most important quality in a piece of software is simplicity. How panglossian, imagining the best of all possible worlds. Well, the world is intrinsically complex, as Fred Brooks explained in his No Silver Bullet essay from 1986[0]. "The complexity of software is an essential property,…

Anyone who has spent any time developing anything but a tiny software system knows that the biggest impediment to productivity (feature delivery, bug fixing, etc) is the complexity of the system at hand. In a sense, this post is simply stating the obvious. The biggest differentiator of skilled software practitioners is the ability to construct simple systems. To call this claim panglossian or meaningless is to hold t…

You are making the common mistake of confounding essential complexity with accidental complexity. One you are stuck managing and one you can eliminate with skill. The world isn't getting less complex just because you work harder on your software.

Re: Simple, correct, fast: in that order

#258

Post by dcre »

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 it's not simple, it might be incorrect and you'd never know until it bites you.

Re: Simple, correct, fast: in that order

#259

Post by jmilloy »

Understandably, a lot of people are balking at the idea that simple might come before correct. Code that is simple but not correct is not a solution. But the OP is not asserting that simple, incorrect code is a superior solution to complex, correct code. Instead, I think the assumption is that there is a solution that is simple (enough), correct (enough), and fast (enough), and that you are not going to stop until you reach such a solution.

Correct comes before fast not only because you should make it correct before making it fast, but because you should not sacrifice correctness in order to make it fast.

Similarly, simple comes before correct because you should not sacrifice simplicity in order to make it correct (or fast). Instead, you should continue looking for different ways to make it correct while maintaining simplicity.

Re: Simple, correct, fast: in that order

#260

Post by Buttons840 »

michaelcampbell wrote: post #32
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.

Sometimes I try to implement a common task in a new library, and I find that if I chain these 4 API calls and then extract some data with a regex, it will do what I want. I rarely actually implement the task this way though, because I know it's a common task, and there must be a better way. Sure enough, after some more research and reading of documentation I find one simple API call that does what I want.

I take this to the extreme, I probably wouldn't implement the complicated API / regex chain without 4+ hours of reading documentation and other research. It bothers me that much. If it seems like a simple and common task, I refuse to believe that there isn't a simple API call already to do what I want, I just have to find it. Sometimes, the simple API call really doesn't exist though, and you have to do what you can, with some comments explaining why.

I've noticed some developers will implement the 4 API chain followed by a regex as soon as they find it, and never give a second thought that there might be a simpler way.

Post reply on HN