The economics of a slow but productive Ruby

[ara.t.howard]

[1] It's interesting to note however that 67% of that figure is still
in paid salaries, rather than the cost of the hardware itself. If
you've got a super sysadmin who can manage 100 boxes (and you better
be paying them at least 80K if they are that super), the hardware
budget will scale a lot better. There's a lot to be said for getting
your hands on a good sysadmin...

Ah, but does SuperSysAdmin have to use a slow scripting language?

As others have mentioned, the scripts used by sysadmins aren't really
CPU intensive nor too dependent on the host language speed. So it's a
moot point.

i wouldn't agree with that. we just started a trio of ruby scripts running
across three machines which coordinated processing of 30 satellite years of
data. they are going to peg the machines near 50% for 3-5 months. it may not
be common but, where huge data sets are involved, something as trivial as
'unpacking and moving some data' may take a considerable amount of logic and
cpu.

2 cts.

-a

 

[Francis Cianfrocca]

My purpose was never to propose that certain values of X or Y are
correct, but rather to provide a framework equation inside which
different values of X and Y can be examined.

This is interesting as far as it goes, but the challenge I have with
it is that I'm not sure the things you propose to measure are
necessarily that important in the economics of many projects (and
"economics" appears in your thread title).

We programmers tend to fantasize that what we do is the most important
part of any effort that involves software development but in many
organizations that's far from true. In particular I would guess that
there is more sensitivity to machine requirements since they tend to
involve capex and often represent a variable cost component in any
project. You may find this bizarre, but many companies view
programmers as human resources, which carry a wide range of
incremental costs going far beyond their variable contributions to any
particular project. If you make the commitment to hire a person as an
employee, it's very difficult for a whole range of reasons to let the
person go. From that point of view, a programmer is a lot like a fixed
cost. Their availability may constrain the number of projects you
attempt but not necessarily their direct cost, as it impacts your
choice of development platform. Outsourcing or using consultants
changes this calculus, but you still have to provision maintenance and
support programmers.

I would guess (though I have no data to back this up) that Ruby finds
far more acceptance in projects where the developers themselves are
the ones making the financial (or time) commitment. Under those
circumstances it's a no-brainer to use a development system that 1)
you dearly love, and 2) you are convinced will save you a lot of time,
and 3) you're convinced will let you get the job done with fewer
people. Many people who fund corporate projects couldn't care less
about 1), and think that 2) and 3) are mutually exclusive.

 

[Jacob Fugal]

i wouldn't agree with that. we just started a trio of ruby scripts running
across three machines which coordinated processing of 30 satellite years of
data. they are going to peg the machines near 50% for 3-5 months. it may not
be common but, where huge data sets are involved, something as trivial as
'unpacking and moving some data' may take a considerable amount of logic and
cpu.

I accept that those scripts will definitely depend on CPU. Those
aren't the types of scripts I envision as "sysadmin scripts", though.
In my brain (which could easily be wrong, since I've never been a
sysadmin), programs consume resources and the sysadmin -- and his
scripts -- are meant to manage the resources so that they *can* be
consumed by other programs.

Jacob Fugal

 

[Jacob Fugal]

This is interesting as far as it goes, but the challenge I have with
it is that I'm not sure the things you propose to measure are
necessarily that important in the economics of many projects (and
"economics" appears in your thread title).

We programmers tend to fantasize that what we do is the most important
part of any effort that involves software development but in many
organizations that's far from true. In particular I would guess that
there is more sensitivity to machine requirements since they tend to
involve capex and often represent a variable cost component in any
project. You may find this bizarre, but many companies view
programmers as human resources, which carry a wide range of
incremental costs going far beyond their variable contributions to any
particular project. If you make the commitment to hire a person as an
employee, it's very difficult for a whole range of reasons to let the
person go. From that point of view, a programmer is a lot like a fixed
cost. Their availability may constrain the number of projects you
attempt but not necessarily their direct cost, as it impacts your
choice of development platform. Outsourcing or using consultants
changes this calculus, but you still have to provision maintenance and
support programmers.

I would guess (though I have no data to back this up) that Ruby finds
far more acceptance in projects where the developers themselves are
the ones making the financial (or time) commitment. Under those
circumstances it's a no-brainer to use a development system that 1)
you dearly love, and 2) you are convinced will save you a lot of time,
and 3) you're convinced will let you get the job done with fewer
people. Many people who fund corporate projects couldn't care less
about 1), and think that 2) and 3) are mutually exclusive.

Very good points. Thanks for the feedback!

Jacob Fugal

 

[Chad Perrin]

I would guess (though I have no data to back this up) that Ruby finds
far more acceptance in projects where the developers themselves are
the ones making the financial (or time) commitment. Under those
circumstances it's a no-brainer to use a development system that 1)
you dearly love, and 2) you are convinced will save you a lot of time,
and 3) you're convinced will let you get the job done with fewer
people. Many people who fund corporate projects couldn't care less
about 1), and think that 2) and 3) are mutually exclusive.

These people, who think 2 and 3 are mutually exclusive, have clearly not
read Mythical Man-Month -- but they should. Actually, just reading a
thorough review, or perhaps even the back of the book, might suffice (if
these people are reasonable enough to absorb the information).

When programmers advocate practices that involve hiring fewer of them,
it's a good damned idea to listen.

 

[Chad Perrin]

I accept that those scripts will definitely depend on CPU. Those
aren't the types of scripts I envision as "sysadmin scripts", though.
In my brain (which could easily be wrong, since I've never been a
sysadmin), programs consume resources and the sysadmin -- and his
scripts -- are meant to manage the resources so that they *can* be
consumed by other programs.

. . or, put another way, sysadmin scripts are for administration of
the system, and not for churning data sets from production operations.

As far as I'm concerned, if a "sysadmin script" is eating up significant
system resources during working hours, you've either mislabeled it when
you called it a "sysadmin script" or failed to do your job as a sysadmin
properly. As Jacob indicated, the job of the sysadmin and his/her
scripts is to manage resources, not consume them. The sysadmin scripts
should be pretty much invisible to the people whose work is meant to be
enabled by them.

 

[Dave Rose]

...under my experience what is almost never considered are these
intangibles...
1.) Under Ruby your maintenance costs will be lower (if it's well
written Ruby)...and because of #1...Since a new systems is never perfect
modifications must be made....and this is where Ruby really shines...any
other language will produce an inertia to change that will continue to
make your system diverge from the users wants and the reality of what
your staff can absorb no matter what the current costs etc....NOBODY...
thinks about this...until the premature end of life of your shiney new
system....

 

[Francis Cianfrocca]

These people, who think 2 and 3 are mutually exclusive, have clearly not
read Mythical Man-Month -- but they should. Actually, just reading a
thorough review, or perhaps even the back of the book, might suffice (if
these people are reasonable enough to absorb the information).

It's the darnedest thing. I know plenty of managers who have read
Brooks, and yet when the crunch comes they still pile on the
resources. But I realize you're talking about the design/specification
phase. But don't underestimate the power and importance that managers
get simply by having larger teams and bigger budgets. Saving money in
activities that are cost centers often makes a manager less
influential, not more so. And in turn, it makes the manager's manager
less influential. Ruby's productivity argument is not too likely to
have much impact in these shops.

 

[Stephen Kellett]

In message

get simply by having larger teams and bigger budgets. Saving money in
activities that are cost centers often makes a manager less
influential, not more so. And in turn, it makes the manager's manager
less influential. Ruby's productivity argument is not too likely to
have much impact in these shops.

Its is, but you have to come at it from a different angle. That manager
doesn't reduce his budget, but they do get a lot more done.

Same budget, more useful work done => more kudos.

Stephen

 

[Francis Cianfrocca]

Same budget, more useful work done => more kudos.

You and I must be hanging out in different companies. Most IT
departments I see are being asked to do more with less, and managers
don't usually get extra credit for doing what they are chartered to
do. But in companies that match your experience rather than mine, I
would expect to see a lot of interest in Ruby.

 

[Chad Perrin]

...under my experience what is almost never considered are these
intangibles...
1.) Under Ruby your maintenance costs will be lower (if it's well
written Ruby)...and because of #1...Since a new systems is never perfect
modifications must be made....and this is where Ruby really shines...any
other language will produce an inertia to change that will continue to
make your system diverge from the users wants and the reality of what
your staff can absorb no matter what the current costs etc....NOBODY...
thinks about this...until the premature end of life of your shiney new
system....

I disagree rather strongly with your use of the phrase "any other
language". There is a fair number of other languages that will serve
roughly as well as Ruby, give or take a little. The truth remains that
most other languages would not serve as well in circumstances where Ruby
excels best.

 

[Chad Perrin]

It's the darnedest thing. I know plenty of managers who have read
Brooks, and yet when the crunch comes they still pile on the
resources. But I realize you're talking about the design/specification
phase. But don't underestimate the power and importance that managers
get simply by having larger teams and bigger budgets. Saving money in
activities that are cost centers often makes a manager less
influential, not more so. And in turn, it makes the manager's manager
less influential. Ruby's productivity argument is not too likely to
have much impact in these shops.

I guess there have to be shops that obstinately do things wrong, if only
to make the rest of us look good by comparison.

 

[Stephen Kellett]

In message

You and I must be hanging out in different companies. Most IT
departments I see are being asked to do more with less, and managers
don't usually get extra credit for doing what they are chartered to
do.

Indeed, but they do get extra credit for exceeding what they are
chartered to do, coming in under budget and ahead of schedule or on time
(since most projects overrun both budget and schedule).

But in companies that match your experience rather than mine, I
would expect to see a lot of interest in Ruby.

I've been fortunate enough to work in environments where they have cared
a lot about what got done and how (and if at all possible the managerial
politics would be sidelined). I've worked in other places where they
didn't care. I got to use Java in a large UK telco in 1996 (when it was
months after the public release) despite a corporate ruling that you
couldn't. My managers wanted to test the technology and chose an
internal project that the senior managers wouldn't be able to see. The
project was a success.

More recently I worked at a large CAD corporation R&D office in
Cambridge, UK. They were interested in results above anything else. All
main project work done in C++. Personal helper utilities written in what
you personally wanted to use. Result: C++/Perl/Python in use by
different people, all with good results. I think they would be very
amenable to Ruby.

After I left, I discovered Ruby. I now use C++, assembler and Ruby
depending upon the task. I don't get anywhere near enough chance to use
Ruby though, which is a shame, but that is the nature of the job.

Stephen

 

[Seth Thomas Rasmussen]

It's rarely a matter of economics and statistics. Essentially there is
very little good scientific data on the relative merits of different
development systems. Practically all you can find was done on
productivity and sociology in development was done in the 70s and early
80s.

Beyond that it is really a matter of faith.

Or in this case, mathturbation.

Seriously though, I can't wait until I can put a few numbers into a
computer and have it fart out all my decisions and actions for me.

 

[Gregory Brown]

Seriously though, I can't wait until I can put a few numbers into a
computer and have it fart out all my decisions and actions for me.

42