Focusing on decisions to improve the software end product

The Forrester Blog For Application Development & Program Management Professionals had a post on a 21st Century Software Development Process that reminded me of one of my favorite topics – the need for programmers, especially Agile programmers, to get on…

The Forrester Blog For Application Development & Program Management Professionals had a post on a 21st Century Software Development Process that reminded me of one of my favorite topics – the need for programmers, especially Agile programmers, to get on the business rules/decision management train. In writing the post Dave makes some good points and has this to say about Agile:

a focus on culture, knowledge, and skills will instead improve the end product. This change in emphasis is embodied by the Agile methods movement and described nicely in one principle in the Agile manifesto ‘Individuals and interactions over process and tools‘

Now there are four tenets in the Agile Manifesto and this is the first.It has always seemed to me that this one almost forces a proponent of the Agile approach to adopt business rules for specifying the logic in business decisions as, after all, one of the key interactions is between developers and domain experts. Business and domain experts don’t like code or other technical representations and the evidence is overwhelming that they do like rules. Because rules are declarative, rich in semantics and verbose they are easy for business users to understand and even write and this helps the individuals concerned (developers and business users) have a better interaction. In fact I would go as far as to say that a developer who claims to be doing Agile while still writing code that is procedural, terse and focused on syntax is not applying this tenet at all.

The other tenets also show the value of rules and decision management.Working software over comprehensive documentation because business rules can deliver working software that domain
experts can manipulate directly lessening the pressure for documentation. Customer collaboration over contract negotiation because rules allow developers and customers to directly collaborate on the the
implementation of business logic. Responding to change over following a plan
because business rules deliver business agility by making the actual code you
write easier to change both during the project, and after it.

So if you are a developer who likes to say you are doing Agile, are you using business rules or are you just deluding yourself?

BTW I wrote an article on this topic a while back for InfoQ – Agile Rules

Link to original post