
Jeff Atwood is wrong about performance - vaksel
http://compaspascal.blogspot.com/2009/07/jeff-atwood-likes-referring-to-his-blog.html
======
edw519
"Hardware is cheap, programmers are expensive."

 _Mediocre_ programmers are expensive.

Good programmers are the bargain of the century.

If companies would just wise up enough to pay a good programmer 3 times as
much as a mediocre programmer to do 10 times the work, do it right, and do it
so that it can be maintained reasonably, Jeff Atwood's tradeoff would become
moot. But companies generally don't do this, which is probably one of the main
reasons the best programmers go off and do their own.

~~~
lionhearted
100% agreement, yet:

> If companies would just wise up enough to pay a good programmer 3 times as
> much as a mediocre programmer to do 10 times the work...

Very few people have such a good eye for talent. It's really, really hard to
do. Jack Welch, one of the better HR people of all time, said his hiring
success rate was only 2 out of 3 hires working out even towards the end of his
tenure. It's really hard to identify good people, know how they'll change and
adapt over time, create a good environment for them, and so on. Vastly under
ratedly hard. One of the reasons good people are underpaid is that it's often
quite hard to tell them apart from "just okay" people. People are bad at
picking talent - they mistake overconfidence and gregariousness for ability,
they put put premiums on likability and agreeableness, they look for people
who "look like a winner" when that only maybe slightly correlates... hard
stuff. Companies whose managers have technical backgrounds have a better
chance, but it's still quite a difficult challenge.

~~~
edw519
"Very few people have such a good eye for talent."

That's OK because it's not necessary.

Management doesn't need an eye for talent. It needs an eye for demonstrated
performance.

If Programmer A consistently delivers excellent software in x% of the time of
Programmers B thru G, the users/customers love it, and the maintenance costs
are a small % (if they have a way of measuring this), then what the f*&#%@
else does management need to know? Treat Programmer A appropriately or lose
him/her.

Talent is in the eye of the beholder.

Demonstrated performance is on the bottom line.

~~~
wglb
But do managers know how to measure performance? Really?

In an enterprise situation, for example, do "customers" really know if they
love the software, or the presentation that sold them the idea, or perhaps
they asked for something to be built wrong.

I would suggest that "very few managers have such a good eye for performance"
no matter the metric.

~~~
access_denied
When I was a low-level employee using custom-built SAP crap, I could have
easily lost my job if I dare suggest an "improvement" on the software.

------
patio11
_If you have upgraded all your servers without consolidating, year after year,
you will notice that your electricity bill is going through the roof._

I don't know, you can buy an awful lot of electricity for an hour of my time,
and I'm _cheap_... I think the largest deployment my day job supports probably
causes an electricity bill in the hundreds a year range. If you had a meeting
between one PL and two engineers to discuss what to do about the electricity
bill you could cancel the meeting and pre-pay the next few years.

Adjust if you're Google... but you're not Google.

~~~
ankp
It's not cheap, and you don't have to be Google for it to matter. Most of the
time, the costs are just non-obvious to engineering.

Here are some rough numbers.

Power for a single 48U rack usually runs $200-$300/month for two 20amp
circuits (possibly +2 for redundancy). A modern 1U server draws anywhere from
(roughly) 1.66 to 2.5 amps, and you can only use 80% of a circuit's maximum
supported load due to safety regulations, resulting in a total supported count
of between 12 to 19 mid-range servers per rack. Higher-end servers have a
significantly increased power draw, but potentially higher efficiency, and
there can be a significant advantage to leveraging multi-core systems.

In addition to rackspace and power, each server must obviously be connected to
the network. The switches draw enough power to potentially decrease the number
of supported servers.

Each rack costs roughly $500/month (plus power), and often requires advanced
provisioning to ensure that rackspace is available, and if possible, located
in the same area. It's not unusual to buy an entire block of space well ahead
of actual use to ensure that the business' growth can be accommodated.

Additionally, one requires an operations staff to maintain the servers. Hard
drives fail, backups must be done, hardware must be ordered, tested, and
finally, deployed. Simple deployment of a single server, including the
networking configuration, travel time, and physical work can easily consume
4-8 hours of operations staff time.

When you add together the operational and capital expenditures, I'm not really
convinced that the idea is so simple as "servers are cheap, programmers are
expensive". Servers, electricity, physical space, and the labor necessary to
install and maintain them are not particularly cheap.

I'd propose a new mantra: programmers are expensive, and so are servers and
IT, and so let's try to not be monomaniacally flippant about it. Software can
be easy to write AND perform reasonably well, and to say otherwise simply
appears to be a false dichotomy fronted by those who benefit from it most.

~~~
j_baker
You're still talking about a minimum of 12-19 servers though. I'd imagine that
the average website doesn't use even that. I think that SO in particular is at
3 servers. Maybe if SO explodes, this will become an issue, but an
optimization would likely have to make a difference of a few racks before it
it's even worth considering making an optimization based soley on power
concerns.

~~~
ankp
Whether an optimization is worth pursuing depends on the business
requirements, how much the it costs to implement, and whether there are any
additional gains beyond avoiding power, space, and personnel costs.

Simply picking an efficient (both for the developer, and in terms of
implementation) language/platform can be enough to start with, and will help
you avoid being boxed in later.

------
sho
Nice straw man. Did anyone ever try to say that it's not worth fixing a
1000x-slowdown error because "we'll just buy 1000 times the hardware, that's
cheaper!"?

Obviously there is a balance somewhere between pointless, unmaintainable,
expensive over-optimisation on one end and programmer incompetence, bad tool
choices and ignorance of hardware limitations on the other.

There will be a sweet spot in the middle, possibly different for all projects,
which just has to be figured out by experienced people who knows what they're
doing. Why all this trying to take "sides"? It's like getting all fired up
about which is "better", planes or ships. _They are both good for different
purposes, choose the one that fits your need!_

------
antirez
I guess that when the problem is to really scale _a lot_ the big cost may be
the energy not the hardware, so the performance the coder can bring you for
watt is crucial.

And to use few CPU cycles you need a programmer that is smart enough to know
both computer science to select the best algorithms and data structures _and_
low level programming languages to lower the constant times involved in this
algorithms.

------
wglb
One item left out is floor space. This is a serious consideration, maybe more
serious than electricity. Real estate for your server racks has a cost
associated with it, and it is not so easy to buy/rent in rack-sized
increments.

------
jhawk28
Its a short term vs long term analysis. If you focus on the long term,
programmers are cheaper. Short term, it is easier to throw more hardware at
the problem. The part that makes it difficult to measure is estimating how
fast it will run on the new hardware. Usually if you use good algorithms and
data structures with an architecture that matches the problem, adding hardware
will scale the performance. Mediocre programmers rarely can get this right
unless they are lucky.

------
al3x
This is good advice. ankp's comment is also good advice.

A well-run technical organization shouldn't have to choose between good
programmers, code that performs, and the ability to quickly operationalize new
hardware when necessary. If you're having to choose, you've got more work to
do.

------
diN0bot
excellent points. plus the author's writing style is direct and if not humble,
than certainly not arrogant.

------
korch
"Jeff Atwood is wrong on the Internet", film at 11. Why is this news?

