From: Francis Cianfrocca Date: 2006-09-12T23:26:21+09:00 Subject: Re: The economics of a slow but productive Ruby On 9/12/06, Jacob Fugal 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.