From: Stephen Kellett Date: 2006-09-13T08:15:40+09:00 Subject: Re: The economics of a slow but productive Ruby In message <3a94cf510609121155l7b6e8452ga1b81d12dc216f4e@mail.gmail.com>, Francis Cianfrocca writes >On 9/12/06, Stephen Kellett wrote: > >> 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. 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 -- Stephen Kellett Object Media Limited http://www.objmedia.demon.co.uk/software.html Computer Consultancy, Software Development Windows C++, Java, Assembler, Performance Analysis, Troubleshooting