Nice article...Comes right up to a major general frustration
|
| Author | Content |
|---|---|
| dinotrac Oct 17, 2006 3:56 AM EDT |
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. OK, I feel better now. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!