Re: The economics of a slow but productive Ruby

On 9/12/06, Francis Cianfrocca <garbagecat10@xxxxxxxxx> wrote:
On 9/12/06, Jacob Fugal <lukfugl@xxxxxxxxx> wrote:
> 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.

Very good points. Thanks for the feedback!

Jacob Fugal

.

Relevant Pages

  • Re: The economics of a slow but productive Ruby
    ... We programmers tend to fantasize that what we do is the most important ... involve capex and often represent a variable cost component in any ... the ones making the financial commitment. ...
    (comp.lang.ruby)
  • Re: Writing bulletproof code
    ... Good software design requires that you put error ... > the 'C' language and the libraries. ... It doesn't actually solve the problem that programmers are ... very few know when the cost will be negligible ...
    (comp.programming)
  • Re: Intro to Programming w/ Machine Language
    ... >> produced disk drives that are as fast as current technology allows ... And you're forgetting a crucial point here: there are manufacturing ... drives that affect the final cost. ... programmers get a "get out of jail free" card ...
    (comp.programming)
  • Re: Intro to Programming w/ Machine Language
    ... >> produced disk drives that are as fast as current technology allows ... And you're forgetting a crucial point here: there are manufacturing ... drives that affect the final cost. ... programmers get a "get out of jail free" card ...
    (alt.lang.asm)
  • Re: What is the benefit to me of .NET as an end-user?
    ... even if moving to a new tool or framework were to double programmer ... 5% improvement in the productivity of the process. ... Since the cost of moving ... programmers using it that it is worth the cost, in the short run, when ...
    (borland.public.delphi.non-technical)
Loading