Ch-ch-ch-changing....

Brad Appleton posted a great little piece on Unchangeable Rules of Software Change - Redux. He makes some great points in the article and I am going to shamelessly steal some. He identifies three pitfalls that are very pithy:

• Pitfall #1: No scope change-management so change overwhelms the team
• Pitfall #2: React to pitfall #1 by trying to prevent scope changes - "if only the requirements would stop changing before a single line of code is written, then the schedule wouldn't keep fluctuating so much"
• Pitfall #3: Requirements Analysis Paralysis to try and prevent problems

His summary - "It's those darn users/customers/analysts that don't know what exactly they want at the outset. It's all their fault!" -  is perfect. This is the basic driver for many business rules implementations - those focused on rules that change often (one of the four types of justifications for business rules).

Brad then outlines some rules that I also really liked:

• Rule #0: Change is Inevitable!
• Rule #1: Resistance is Futile! - There isn't a darn thing you can do to prevent Rule #0.
• Rule #2: Change is like Quicksand -- Fighting it only makes it worse!
• Rule #3: Change is like Quicksilver -- Tightening your grip makes it slip from your grasp!
• Rule #4: Embrace change to control change

and for which I would like to propose James corollaries:

• Corollary #1: Nothing you can do will stop users changing the way their systems decide things unless you can stop the world itself from changing
• Corollary #2: Users must become responsible for and empowered to execute their own changes unless you happen to like doing maintenance work
• Corollary #3: IT's role in this is to help users do this without getting themselves into too much trouble or impacting other users and other systems
• Corollary #4: The technology you use for a system should be selected, in part, on its ability to help users do this.

As you might imagine this is a regular topic on the blog. You might want to check out Business and IT collaboration or Agile Rules? A "conversation" with Scott Ambler. There are many articles on requirements and business rules and some rules FAQs that are also relevant.