On Mar 4, 5:07 pm, Phoenix Rising <[email protected]> wrote:
> I'm trying to "grok" agile practices in "the real world". I've read > the Agile Manifesto (http://agilemanifesto.org/), and I find it > somewhat vague. Most of this is common sense, but the one thing that > irks me (probably because I don't understand it fully) is that > "responding to change" is more important than "following a plan". I dunno. I'm big on plans - but I'm big on them being flexible. Maybe that is the same as responding to change, but I like to think of it as making it easy to modify the plan. > Here's where agile practices come into play, and where the "rub" is: I > had an entire system finished and ready to go. Then management > stepped in, and for the third time in two months, changed it all. > Four user types got expanded to 9, and instead of 4-8 sub parts for > each user calculated differently, that got expanded from 4-15. The > changes were so sweeping that there was no way to simply "modify" > existing code. I had to start over again from scratch. I'd say this doesn't have so much to do with rails or agile, as it does with OOA&D - and various OO Design Patterns. http://en.wikipedia.org/wiki/Design_pattern_(computer_science) http://en.wikipedia.org/wiki/Behavioral_pattern http://en.wikipedia.org/wiki/Design_Patterns_(book) You have a set of knowns: 1. Management is going to change things 2. There are users - and there are different kinds of users. 3. There are sales - and there are different kinds of sales. 4. Calculating commissions is going to be arbitrarily complex and will change. You know there are always going to be users. And you know there are always going to be sales. It seems like those objects should be pretty concrete and basic. It sounds like you might want to decorate (http://en.wikipedia.org/wiki/Decorator_pattern) users to differentiate them instead of messing with subclasses. The same goes for sales. Or maybe something even simpler - you could just tag the users and sales using something as simple as acts-as-taggable (http:// rubygems.org/gems/acts_as_taggable). Then when it comes time to calculate totals, maybe use Strategies (http://en.wikipedia.org/wiki/Strategy_pattern#Ruby). If you lay the objects out the right way, maybe the next time management changes how commissions are calculated all you need to do is change a few tags and modify/add some strategies. Or maybe they will decide that it depends on how many friends you have in Facebook - in which case you might need to do more coding. They are management, after all. --- Kurt Werle I am looking for a new Rails job: http://www.circlew.org/kurt/pages/resume -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
