« The challenge for Enterprise Applications | Main | Mr. Scrooge Would Approve »

Using business rules to avoid "Write-only" code

I found out about this post about 20 rules for a software project by reading a post about it on the Tyner Blain blog. There was a great expression in the second posting where they talk about "write-only" code or code that simply is not readable. This made me think about how much code is "write-only" and why that's a particular problem when the code is implementing business logic - the rules that drive how your business behaves. Looking back at Rishikesh's original post I thought that this concept really links two of the 20 points:

1. Make sure you know what you are building. Many project delays are because the “customer”- the manager, corporate head, (you?) doesn’t actually know what they want.

14. Be fanatical about the readability of code.

I have blogged before about the reality of change and that there is no way to stop "customers" from changing what it is they want. It's also true that even if your customers know what they want when you start the majority of the lifetime of the code you are writing is going to be in the "change time" period after the first version is done when changing realities cause the needs of the code to change. This means you cannot build to last but must build to change. So, much as I like the list, I am not sure that point #1 is a reasonable one. I might propose, instead, something like this:

1. What you need to build will change all the time. Make sure the “customer”- the manager, corporate head, (you?) - who can say if the code does what it should is part of the process, part of the team

This of course leads straight into #14. Nothing can be maintained easily unless it can be understood. Where I would go further is to say that it is not enough for other programmers to be able to read the code - the people who understand the purpose of the code must be able to read it, or at least some of it. Ideally you want them to be able to actually participate in the ongoing management of the business logic that represents your business embodied in your code but business users don't want to maintain code, which means you need a way to have them manage the "code" without seeming to. Which brings use to using business rules especially to their value relative to code in this respect. I might therefore replace 14 with something like this:

14. Be fanatical about the readability of code and remember who needs to be able to read it

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 avoid "Write-only" code:

» Reducing maintenance with business rules from James Taylor's Decision Management
I saw this post on Rajgo's blog - Five reasons to use Business Rules to Reduce Maintenance. He discusses a piece by Jeroen on code maintainability that has four key attributes. While the post made most of the key points... [Read More]


Rishikesh Tembe

You bring up good points. Regarding #1, I agree that the product needs and requirements will change over the life cycle of the project. When I say "Make sure you know what you are building", I mean that over time.

When the customer requirements do change, the project team including management, engineering and QA has to ensure that they understand the details of the change as well as the reasons behind it. This knowledge should also then be reconciled with the product strategy, and modifications made if necessary.

Thanks for the feedack. I need to edit my post for clarity.

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.