Copyright © 2009 James Taylor. Visit the original article at Hardcoding + procedural code = bad news.
In a blog post about Hardcoding Considered Harmful – or is it? Jeff Palermo said
Oren Eini boldly makes the assertion that a system is simpler to maintain when configuration is hard-coded in one place within the system. Coupled with an automated testing and deployment process, changing configuration can be just as simple and predictable as possible. Oren asserts that hard-coding as much as possible enhances maintainability. He then defends his position with an example in a subsequent post.
In the example post Oren has this code snippet:
public class DiscountPreferredMembers : OnOrderSubmittal
{
public override void Execute()
{
if ( User.IsPreferred )
Order.AddDiscountPrecentage(5);
}
}He goes on to say:
We hard code the rules, which is the easiest approach to getting things done. Because we have a structured way of doing that, we can now apply the ways in which we use it. For instance, if we wanted to support runtime replacements of rules, that is easy, all we need to do is to provide a FileSystemWatcher and reload them. If we want to add a rule, we just create a new class for that. If we want to modify a rule, we go and change the hard coded logic.
Wow – the things a programmer will describe as simple! What if this had been hard-coded in a Business Rules Management System or BRMS?
- It would still be hard-coded and easy to write.
- It would be deployed as a simple to use, structured component just as Oren describes.
- If we wanted to support runtime replacement of the rule we would have to do nothing (the BRMS already handles that).
- If we wanted to add a rule we would just add a rule – no need to create another class.
- Modification of the rule would be about the same.
The differences become more extreme as the complexity of the decision we are talking about increases. If there were 5 or 10 or 100 rules that had to be applied, as there often are in discount scenarios. Now we would end up with either lots of classes and/or methods and nested if..thens. Not with business rules – just a simple, flat list of rules that are easy to read, easy to manage and easy to change. The problem with this example is not so much that it has been hard coded as that it has been hard-coded in a language that is, to quote Ira Fuch
…syntactic, abbreviated, and procedural, as opposed to semantic, verbose, and declarative
Hard-coding in business rules would dramatically improve the approach Oren proposes. Indeed many BRMS customers do exactly this – they use the BRMS and the business rules syntax but they continue to hard code the rules behind their decisions – developers just write rules, not code pretending to be rules. Now Jeff goes on to say:
I agree with Oren. The first draft of some functionality should hard-code everything. Then subsequent revisions will cause some information to be factored out into mediums that can be maintained while suppporting all the requirements in scope. The requirement cause us to make decisions about what information to hard-code and which information to soft-code.
I understand the point Jeff and Oren are making here – soft-coding things can make them more complex than is necessary and can, especially if done thoughtlessly, create maintenance problems. However hard-coding in traditional procedural languages like Java or C# means creating a procedural and abbreviated piece of code that will become increasingly hard to maintain as its complexity increases and that business users will not find approachable or easy to understand. Hard-coding in business rules avoids this problem and, when something does need to be “soft-coded”, a BRMS allows the easy transition to business user rules management using template-driven or other approaches layered on to the same underlying rules execution and management environment.
Hard-coding may not be harmful absolutely all the time but coding business rules in code probably is.
