Reddit pointed me to this post on "Writing Maintainable Code" by Jeremy D. Miller over on CodeBetter.com. 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: application maintenance, BRE, BRMS, business agility, business rules, change time, maintenance, programmer, programming, agile
