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.
