Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?
Ruby on Rails seems to be a lightning rod for controversy. At the heart of most of the controversy lies amazing productivity claims. This article explores the compromises and design decisions that went into making Rails so productive within its niche and how Ruby on Rails, like a nail gun, saves so much time.
Ruby on Rails seems to be a lightning rod for controversy. At the heart of most of the controversy lies amazing productivity claims. Rails proponents boast of incredible productivity, with some claims of 10 to 1 over Java development. This article explores the compromises and design decisions that went into making Rails so productive within its niche and how Ruby on Rails, like a nail gun, saves so much time.
Nice article on some Rails niceties. I've just dipped my toes in Rails and like it.
One thing the author mentions is a variation on my basic complaint with the way most companies seem to implement their overall code development process.
He mentions the power of a feedback loop for developers.
Hell, yes!!
It is a wonderful thing. It is the power of release early, release often. It is iterative in nature. It, without quite saying so, is a recognition that trial and error (the way that nature has managed to produce every living thing on this planet) is more powerful than our mighty cerebral wetware.
I don't dismiss the importance of good design and careful work, but development methodologies need to facilitate recovering from mistakes, re-thinking design decisions, etc. It needs to be simple to just go ahead and try something out to see if it works.
That's the big fallacy of waterfall development and the value-add of iteration. We're never as smart as we think we are.
And yet...corporate development processes are determined to waste time and money running from the truth.
Up-front work has gotten too much respect.
I blame Object Orientation to some extent. When OO methodologies first appeared, many of us recoiled by how much work it took up front to do anything. The response was, "Well, you should be doing that up-front work anyway".
Sure, there's a lot to do -- especially on interfaces between development groups, but up front happens to the time when you know the least. That's why manufacturing processes make prototypes.
My favorite fable is a common corporate aproach to "agile programming" -- instead of actual interation, they split a project into phases. It's really just a waterfall with brakes. Real agility almost requires you to throw something away. It means putting something up and trying it out. If performance is a concern, it means measuring that. It might mean (probably should mean) letting clients/and or customers try a test version and getting reactions. THEN, with your new knowledge, you revisit things, throwing out code if you have to.
For Pete's sake -- that's what happens when we re-factor crap, it's just that development plans aren't built for "well, we didn't quite know what we were doing so we had to go back and make it right." Better to make that a strength than an admission.
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
One thing the author mentions is a variation on my basic complaint with the way most companies seem to implement their overall code development process.
He mentions the power of a feedback loop for developers.
Hell, yes!!
It is a wonderful thing. It is the power of release early, release often. It is iterative in nature. It, without quite saying so, is a recognition that trial and error (the way that nature has managed to produce every living thing on this planet) is more powerful than our mighty cerebral wetware.
I don't dismiss the importance of good design and careful work, but development methodologies need to facilitate recovering from mistakes, re-thinking design decisions, etc. It needs to be simple to just go ahead and try something out to see if it works.
That's the big fallacy of waterfall development and the value-add of iteration. We're never as smart as we think we are.
And yet...corporate development processes are determined to waste time and money running from the truth.
Up-front work has gotten too much respect. I blame Object Orientation to some extent. When OO methodologies first appeared, many of us recoiled by how much work it took up front to do anything. The response was, "Well, you should be doing that up-front work anyway".
Sure, there's a lot to do -- especially on interfaces between development groups, but up front happens to the time when you know the least. That's why manufacturing processes make prototypes.
My favorite fable is a common corporate aproach to "agile programming" -- instead of actual interation, they split a project into phases. It's really just a waterfall with brakes. Real agility almost requires you to throw something away. It means putting something up and trying it out. If performance is a concern, it means measuring that. It might mean (probably should mean) letting clients/and or customers try a test version and getting reactions. THEN, with your new knowledge, you revisit things, throwing out code if you have to.
For Pete's sake -- that's what happens when we re-factor crap, it's just that development plans aren't built for "well, we didn't quite know what we were doing so we had to go back and make it right." Better to make that a strength than an admission.
OK, I feel better now.