Hacker News new | ask | show | jobs
by chatman 4119 days ago
Just comes to show how careless Ruby guys were while building this.
2 comments

1. Make it work 2. Optimize
From working with Ruby guys its normally 1. Make it work 2. Spin up more AWS boxes
Nothing's wrong with spinning up more AWS boxes. If it costs 300$ annually to solve a problem that would cost 5k$ in development to fix, I believe it's a wise choice.

Yeah, down the line you will eventually have to do optimization, but you will prioritize.

A agree somewhat, but I've seen 10 box systems that could run on raspberry pie with good code
I wasn't advocating for badly written code to run on a whole datacenter. I was just pointing the alternative with the assumption that the code was somewhat healthy and adding one new instance to cover the sub-optimization wasn't a big deal.

Of course, if you have 10k users and it runs on 3 machines, you got a problem which no amount of boxes can solve.

I've seen them. I've worked on them. But again, where's the cost/benefit?
I'm hardly what most environmentalists would call an "environmentalist", but one cost here is the increase in carbon footprint. Of course, to the company the cost/benefit analysis errs on the side of just spinning up more boxes. But from a larger perspective, taking some extra time to make more efficient use of machines could have a drastic impact. Many optimizations don't require months to implement. Many of those are even avoidable with a bit of foresight.
In a certain, quite limited model of economics that could actually be named as "wise".

Once a more holistic view is taken, wide spread total costs and benefits are taken into consideration, once costs are not only defined as money flowing out of my own pocket, once not only "Gesinnungsethik" but also and more importantly "Verantwortungsethik" gets applied, well,

in such a world we would probably wish, that Amazon would change its pricing policy to:

- get the first 2-5 AWS instances almost for free

- and pay for the next few 100 exorbitantly much more money.

We all would benefit from the cultural, technological and social changes this would help to spark, I think.

But who am I to question current culturally entrenched "economic" thinking...

What social changes would you expect from the pricing policy changes of marginal EC2 instances?
"social changes from the pricing policy changes of marginal EC2 instances" sounds ridiculous when given this context, right?

It changes when the context are not "marginal EC2 instances" but instead energy and resources burning machines, used (often) by ignorant software developers and their organizations allowed and actually encouraged, partly even actively driven into such purely self beneficial behavior models.

For a definition of social: http://en.wikipedia.org/wiki/Social ... obviously driving software development into a scarcity of computing power would haven "social" consequences: in the development teams f.e. interactions and priorities would need to change dramatically.

But maybe software development turned almost into a "commodity" because of the commoditization of computing power available to even the most ineffective mental artifact aka program.

And that in turn was possible in large extent by off-loading the true costs of assembly / dis-assembly / disposal and the resources needed to build those machines onto people in underdeveloped regions of the world...

Now what could the social change be, the more expensive computing devices could allow for in those regions?

If people cared about "effectivity" not only via a detour to "uh, i need to recharge my phone, again?!" f.e. but essentially because because they would have to pay the true cost for their ineffective setup of hardware and software?

What could the social change be... ;)

"AWS? What is this? I just use Heroku..."
"The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." — Michael A. Jackson
I prefer full quote from Knuth:

    "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
I have the problems with many happy-coders that they only remember the part about about not optimizing early and often forget that part when you should measure performance, find bottlenecks and get rid of them.
ok, now i have to rephrase my statement: 1. Make it work 2. Measure 3. Optimize

What people often miss is the measuring part.

It's important not to skip step 2, though. Give everything a nice once-over for writing documentation and considering changes to API and algorithm.
Careless comes across as a bit negative, try care free.