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: BRE, BRMS, business agility, business rules, programmer, programming, requirements, change time