3 ms·

One of the points this article made that I like, and argued for in the other thread was "what matters is fast enough" people love saying X is too slow etc, th

One of the points this article made that I like, and argued for in the other thread was "what matters is fast enough" people love saying X is too slow etc, the only thing that matters is the ability for X to perform up to your requirements, if you need a million concurrent users then yes access will be the wrong tech. but to say X is too slow, you must specify exactly what it is too slow for.

patio11 17y ago
I agree wholeheartedly, although I have to make the pointy-headed objection that fast and scalable are two different things. You can have a system which scales wonderfully and still takes unacceptable time for pages to render -- if so, you fail. You can also have a system which can't push over 100k page views in a day but renders snappily for those lucky folks -- and if your business model can win on 100k page views a day then you're doing pretty well for yourself now aren't you. Please, God, send me scaling problems. I want my hardest problem in life to be too many people trying to give me money. (Is it just me or does the "My framework scales better than yours!" argument always rage in inverse proportion to the amount of money at stake per page view? I've seriously never heard it "Whoops, we had this great app people were paying real money for but we outgrew our old framework and needed a rewrite." Probably because the solution would be "Hire somebody to do it while sipping iced teas on a beach in Tahiti.") I also think people need to be beaten around the head with the YSlow presentations until they get the point: 80% of the user perceptible delay happens on the front end. It does not matter whether you are running Rails or a CGI script written in hand-coded assembly -- stupid little things on the front-end like whether you gzipped your HTML or combined and minified your assets matter more in terms of user-perceived speed. But instead of adapting to that measurable, objective truth of our profession (where best practices are literally along the lines of "There is one line in your Apache configuration which will make HTML gzipped. Make sure it is on.") we waste time dickering over "shootouts" to see which backend gets to wait on IO or wait on rendering 100 ms faster. Some days we're like the surgeons who scorn checklists because checklists are too easy to possibly save half of the lives lost during surgery.
- stcredzero 17y ago
  It's just like "street racers" who badmouth each other's cars because it has this, or doesn't have that. We programmers also succumb to primate instincts that subconsciously have us perpetrate verbal aggression on one another. However, it is worthy to note that real racers spend their time honing their skills or gathering resources in preparation for actual races. It has been noted that some of the best street racers drive like grannies most of the time, because they're saving all their resources for when it really matters.
nazgulnarsil 17y ago
to generalize: 1. people often over optimize because they mistakenly believe that every feature matters. 2. If your time is worth $50 an hour researching ways to save $40 for an hour isn't worth your time. 3. the harder a time you have deciding between two things the less likely the decision matters. you're having a hard time because the two choices have similar utility. and of course this is all just a subset of the larger skill of prioritizing in general. I find a useful exercise is when deciding to invest something (time, money) jot down a quick list of other things you could be doing and see if any of them are obviously better.
moe 17y ago
And in the other thread you were called out (by me and others) for this false statement, because you are wrong. What really matters is: "scalable enough". That's a big difference because today's hardware is very forgiving. Today you can do really stupid things, like write a chat-service that dispatches all messages through an on-disk database, and it will work. Ten years ago that thing wouldn't even have gotten off the ground. The question remains whether your little toy project will scale to worthwhile workloads. You know, to serve a purpose (novel concept). This is where this CouchDB nonsense falls apart. Neither would it possibly scale to any worthwhile number of users. Nor does it present any particular elegant or interesting programming concepts. It's not more or less than the implementation of a horrible anti-pattern. I don't mind that (we had a good laugh, after all) but the author should really stop trying to sell this under the slogan of "Simple wins" - as if any of what he did was a good idea. Simple did not "win" anything here. And to add insult to injury: His solution is not even "simple" by any means. I can write the same thing in under 100 lines of Python or Perl, without involving an esoteric database, and it would scale better.

patio11 17y ago

I agree wholeheartedly, although I have to make the pointy-headed objection that fast and scalable are two different things. You can have a system which scales wonderfully and still takes unacceptable time for pages to render -- if so, you fail. You can also have a system which can't push over 100k page views in a day but renders snappily for those lucky folks -- and if your business model can win on 100k page views a day then you're doing pretty well for yourself now aren't you. Please, God, send me scaling problems. I want my hardest problem in life to be too many people trying to give me money. (Is it just me or does the "My framework scales better than yours!" argument always rage in inverse proportion to the amount of money at stake per page view? I've seriously never heard it "Whoops, we had this great app people were paying real money for but we outgrew our old framework and needed a rewrite." Probably because the solution would be "Hire somebody to do it while sipping iced teas on a beach in Tahiti.") I also think people need to be beaten around the head with the YSlow presentations until they get the point: 80% of the user perceptible delay happens on the front end. It does not matter whether you are running Rails or a CGI script written in hand-coded assembly -- stupid little things on the front-end like whether you gzipped your HTML or combined and minified your assets matter more in terms of user-perceived speed. But instead of adapting to that measurable, objective truth of our profession (where best practices are literally along the lines of "There is one line in your Apache configuration which will make HTML gzipped. Make sure it is on.") we waste time dickering over "shootouts" to see which backend gets to wait on IO or wait on rendering 100 ms faster. Some days we're like the surgeons who scorn checklists because checklists are too easy to possibly save half of the lives lost during surgery.

stcredzero 17y ago
It's just like "street racers" who badmouth each other's cars because it has this, or doesn't have that. We programmers also succumb to primate instincts that subconsciously have us perpetrate verbal aggression on one another. However, it is worthy to note that real racers spend their time honing their skills or gathering resources in preparation for actual races. It has been noted that some of the best street racers drive like grannies most of the time, because they're saving all their resources for when it really matters.

nazgulnarsil 17y ago

to generalize: 1. people often over optimize because they mistakenly believe that every feature matters. 2. If your time is worth $50 an hour researching ways to save $40 for an hour isn't worth your time. 3. the harder a time you have deciding between two things the less likely the decision matters. you're having a hard time because the two choices have similar utility. and of course this is all just a subset of the larger skill of prioritizing in general. I find a useful exercise is when deciding to invest something (time, money) jot down a quick list of other things you could be doing and see if any of them are obviously better.

moe 17y ago

And in the other thread you were called out (by me and others) for this false statement, because you are wrong. What really matters is: "scalable enough". That's a big difference because today's hardware is very forgiving. Today you can do really stupid things, like write a chat-service that dispatches all messages through an on-disk database, and it will work. Ten years ago that thing wouldn't even have gotten off the ground. The question remains whether your little toy project will scale to worthwhile workloads. You know, to serve a purpose (novel concept). This is where this CouchDB nonsense falls apart. Neither would it possibly scale to any worthwhile number of users. Nor does it present any particular elegant or interesting programming concepts. It's not more or less than the implementation of a horrible anti-pattern. I don't mind that (we had a good laugh, after all) but the author should really stop trying to sell this under the slogan of "Simple wins" - as if any of what he did was a good idea. Simple did not "win" anything here. And to add insult to injury: His solution is not even "simple" by any means. I can write the same thing in under 100 lines of Python or Perl, without involving an esoteric database, and it would scale better.