« Book Review: Data Mining Techniques | Main | Predictive Analytics: Aisle 3 »

Using business rules to write maintainable code

Reddit pointed me to this post on "Writing Maintainable Code" by Jeremy D. Miller over on It's a nice article and I look forward to reading the rest of his posts on this topic.There's lots of good stuff but a number of his comments led me to dig up some of my posts on maintainability and agility:

"Enable Change or Else!" because "Change is a constant in an enterprise software system"

Regular readers will know how much I agree with this. I have written before about how rules can help you love change and construct dynamic applications built with change in mind. Using business rules for core business logic can also help you respond to changing requirements. This is sometimes called business agility and I wrote some notes on agility based on some Gartner research on this topic.

"single most important quality for an enterprise software system is maintainability"

I recently posted on using rules to avoid "write only" code and on using rules to improve the application maintenance process.

Jeremy has "a strong preference for creating maintainable code throughout the codebase" rather than building in points of extensibility.

While I think he is right, I also think that the reality is that some parts of an application will have change driven by business users and some by more technical requirements.. Jeremy asks the question "where should this code go" and I think there should be a follow-up question of "what kind of code should this be". Assuming that everything in an application should be code is a risk as there is a problem with (our expectations of) programmers. After all you have to remember the different perspectives of programmers and business people.

Jeremy then lists some great questions along with proposed approaches to address them. Some of them seem to me to relate very strongly to business rules:

  • Can I find the code related to the problem or the requested change?
    And once I find it can someone who understands the change also read the code?
  • Can I understand the code?
    And who am "I"? A programmer or someone who runs the business?
  • Is it easy to change the code?
    Can I change the "rules" and put new rules into production without downtime?
  • Can I quickly verify my changes in isolation?
  • Can I make the change with a low risk of breaking existing features?
  • Will I know if and why something is broken?

All these points lead to me repeat some of my thoughts on why business rules can be better than code and on business user rule maintenance secrets.

Lastly he has a very strong focus on the value of layering and separation of concerns. He identifies one layer as "Business logic, rules, domain model". Could not agree more.

As an aside he also talks about agile methods. I have posted a virtual conversation with Scott Ambler on rules and agile approaches and an article on the same topic if you are interested.

Technorati Tags: , , , , , , , , ,

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:


TrackBack URL for this entry:

Listed below are links to weblogs that reference Using business rules to write maintainable code:



Nice article.

The Last link does not work

The comments to this entry are closed.

Search Site



  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.