I saw this post on Better Projects and it reminded me of days spent writing a RAD methodology for Ernst and Young. RAD, or Rapid Application Development, uses prototyping and lots of short iterations to keep a development project on track. The post has a nice graphic showing the cycles within cycles used in the approach and it got me thinking about rules. Applying business rules in such an approach offers three benefits:
- Logic, rules, can be changed collaboratively by business users and developers together. This will improve the quality of elements that are less easy to “see” when prototyping.
- Often the class of rule is easy to identify (cross-sell rule or eligibility rule) but the specific rules change constantly. Using rules the application development can continue once the developers know when rules of a certain type are to be executed. The rules themselves can be built by business users based on templates and this can be de-coupled from the main development thread.
- The final code delivery is not the end as the rules are easy to change and evolve without damaging the application as a whole, reducing the pressure to “get it right” before shipping something useful.
Like Craig I just could not resist the blinking lights….
