3 ms·
The right tool in the right hands will certainly give you that kind of advantage. It's not in language alone, but combined with the craftsman, the level of tru
by fleitz 14y ago
The right tool in the right hands will certainly give you that kind of advantage.
It's not in language alone, but combined with the craftsman, the level of trust in the team, and the process, certainly.
Once you have 200 programmers you have to have managers, architects, etc, and you have communication overhead. I'd say off the top your communication overhead is 50%, so lets say you now have 100 programmers available to program, and 100 to communicate. Now to use these 100 programmers effectively you need them to work in parallel, in any project you usually have layers so some programmers simply won't be able to do anything because they are waiting for someone else, lets say outside of meetings these programmers are actually programming 75% of the time, now you have 75 programmers. Lets say java is twice as inefficient in terms of LOC as ruby, now you have 35 programmers, lets say a ruby rockstar is 10X what the average java programmer is, now you have 3.5 programmers.
When you walk into your typical large corporate dev shop you can take on many times the workforce with a small team of dedicated craftsmen who trust each other.
Whether it's 50:1, 100:1, or 200:1 I'm not sure, but I am sure that it's in that ballpark.
- jacquesm 14y agoI challenge you to write an application like Wowza in ruby. Java is insanely performant for some workloads, as a long time C hacker I think that is interesting because this used to be an area where C was unchallenged and now java has achieved parity there, and in some situations can exceed C. Ruby and other glorified scripting languages need not apply. LOC is not a useful measure for productivity anyway, I thought we had put that to rest a while ago. What matters is whether or not the stack you are using gives you what you need, if what you need is fewer lines of code because you've made that a metric then you are missing the wood for the trees. Long term what matters is maintainability, control of the development process (which you should be able to achieve in any environment but which appears to be problematic in some), your ability to find employees and so on. Lines-of-code never was a business deliverable and it should not be, it does translate into some measure of cost in the longer term but that cost can be offset by lots of factors.