# \[slightly OT\] Grokking agile practices

**URL:** <https://www.ruby-forum.com/t/slightly-ot-grokking-agile-practices/184598>\
**Category:** Rails\
**Created:** [March 5, 2010, 2:09am UTC](https://www.ruby-forum.com/t/slightly-ot-grokking-agile-practices/184598 "2010-03-05T02:09:13Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Phoenix\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/5e9695/32.png) [@Phoenix\_R](https://www.ruby-forum.com/u/Phoenix_R)\
**Post date:** [March 5, 2010, 2:09am UTC](https://www.ruby-forum.com/t/slightly-ot-grokking-agile-practices/184598/1 "2010-03-05T02:09:13Z")

</div>

I’m somewhat of a newbie to agile practices, and I know the Rails  
community in general is pretty “up to speed” on agile methodologies,  
but if there’s a better place for me to ask this question, let me  
know, and forgive the off topic post.

I’m trying to “grok” agile practices in “the real world”. I’ve read  
the Agile Manifesto ([http://agilemanifesto.org/](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”.

Now, what I’m trying to get, is exactly HOW - in terms of technology  
and practices - we, as software developers, can respond to change  
_over_ following a plan. Let me illustrate with a real life example.

I’m currently working a project for a cell phone company where the  
company supplies a list of employees and a list of sales, and what  
employee made which sales, and which of 4 different types of employees  
they are (retail sales, territory manager, store manager, business  
sales person, etc.). The goal of the project is to calculate the  
commission to be paid to each user (somewhere in the 200 users range -  
it’s a small company).

One problem is that each of those four types has anywhere from 4 to 8  
“sub parts” of their commissions. There’s a separate total for  
activations, a separate total for renewals, accessory sales, and other  
types of sales, depending on the role. Each of these is calculated in  
an entirely different manner, and compared to a “floating modifier”  
table, that is different for each role type, for each type of  
calculation, then re-calculated, etc. It’s a highly convoluted and  
screwed up process, but you know how it is with “management” in a  
corporation…

Now, I’m tying this in with a Ruby on Rails application that serves as  
the company intranet web portal for our entire company as well, so  
this is all tied to the User model within the application.

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.

Because it had to be tied to an already existent User model, I used  
some mixins to structure the different versions of the system (which  
I’m looking at making an entirely separate application, by the way).  
I’d consider this a somewhat “agile” method - keeping code modular;  
but what else could I do?

I also practice TDD fairly well (though I need to teach myself RSpec/  
Cucumber etc.). So of course, each method had tests to back it up,  
and I put a LOT of time and effort into simplifying and normalizing  
the database to keep things within best practices, not duplicate data,  
and “future proof” as best as I could. I find TDD a _big_ help with  
stuff like this, to “prove” that your code works in case anyone starts  
a fight or a political struggle (which is common where I work,  
unfortunately), but more importantly, to facilitate change by making  
sure that changes don’t break existing functionality.

My problem is that short of :

- TDD
- Really thinking hard about how to structure your data
- Using source control (I’m still with Subversion though I want to  
play with git a bit more, get a better feel for the differences  
between them)
- and “modularizing” code conceptually (MVC, mixins, etc.)

I don’t know what ELSE I can do, in terms of agile PRACTICES, to  
respond to change better.

In my experience, change is a daily to hourly occurrence. It’s  
ridiculous in some cases, and I’m wondering: how far can we take the  
“agile” concept? How do we EXECUTE that concept on a day-to-day  
basis? What best practices are there for making change this frequent,  
this sweeping, more manageable?

I want to be a much better developer than I am, and be able to respond  
to these changes in a more “agile” way. I get stuff like this thrown  
at me all the time, and I’m sure I’m not alone in that, but I feel I  
may be behind the times in learning to respond to this better with  
better practices, development techniques, and possibly tools.

Can anybody point me to some resources, comment on how I can better  
respond to changes LIKE this (the above is only for illustrative  
purposes, I’m not looking for “answers” to this situation, just some  
better ways to approach anything similar to it now and in the future),  
etc.?

Thanks a lot for any input you can provide. And again, if this post  
is better suited to another Google talk group or elsewhere, let me  
know and I’ll go put it there, and please pardon the intrusion.

---

<div class="post-metadata">

**Author:** ![Phoenix\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/5e9695/32.png) [@Phoenix\_R](https://www.ruby-forum.com/u/Phoenix_R)\
**Post date:** [March 5, 2010, 6:50am UTC](https://www.ruby-forum.com/t/slightly-ot-grokking-agile-practices/184598/2 "2010-03-05T06:50:42Z")

</div>

On Mar 4, 5:07 pm, Phoenix R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> I’m trying to “grok” agile practices in “the real world”. I’ve read  
> the Agile Manifesto ([http://agilemanifesto.org/](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.

> **[Software design pattern](https://en.wikipedia.org/wiki/Design_pattern_(computer_science))**
>
> In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system....

> **[Behavioral pattern](https://en.wikipedia.org/wiki/Behavioral_pattern)**
>
> In software engineering, behavioral design patterns are design patterns that identify common communication patterns among objects. By doing so, these patterns increase flexibility in carrying out communication.
> Examples of this type of design pattern include:

> **[Design Patterns](https://en.wikipedia.org/wiki/Design_Patterns_(book))**
>
> Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++...

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  
([Decorator pattern - Wikipedia](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://  
[acts\_as\_taggable | RubyGems.org | your community gem host](http://rubygems.org/gems/acts_as_taggable)).

Then when it comes time to calculate totals, maybe use Strategies  
([Strategy pattern - Wikipedia](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 W.  
I am looking for a new Rails job:  
[http://www.circlew.org/kurt/pages/resume](http://www.circlew.org/kurt/pages/resume)

---

<div class="post-metadata">

**Author:** ![Phoenix\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/5e9695/32.png) [@Phoenix\_R](https://www.ruby-forum.com/u/Phoenix_R)\
**Post date:** [March 5, 2010, 8:59pm UTC](https://www.ruby-forum.com/t/slightly-ot-grokking-agile-practices/184598/3 "2010-03-05T20:59:08Z")

</div>

Phoenix R. wrote:

> 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.

Agile practices aside, it sounds like you want to develop a “computation  
engine” that can represent an arbitrary formula (it IS management driven  
after all) out of some number of components. Your key issue would be a  
decent UI for defining these nodes and how they fit together to create  
formulas. Calculations become a relatively simple DFS tree traversal.

Node = [Constant] or [object method call] or [Operator, Node, Node]

Back in the day, I did this with variant record types, and built such an  
engine which could compute bills from utility rate structures, or  
formulate deposition rates of different types of particulates from  
incinerators.

Just food for thought.

---

<div class="post-metadata">

**Author:** ![Phoenix\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/5e9695/32.png) [@Phoenix\_R](https://www.ruby-forum.com/u/Phoenix_R)\
**Post date:** [March 6, 2010, 10:46pm UTC](https://www.ruby-forum.com/t/slightly-ot-grokking-agile-practices/184598/4 "2010-03-06T22:46:31Z")

</div>

Quoting Phoenix R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> I’m somewhat of a newbie to agile practices, and I know the Rails  
> community in general is pretty “up to speed” on agile methodologies,  
> but if there’s a better place for me to ask this question, let me  
> know, and forgive the off topic post.

So I understand your situation better, are you trying to do agile alone  
or has  
management and other stakeholders bought into it?

Jeffrey