JFHCIConsidering Scale

time to read 5 min | 894 words

There are some really good comments in this post, which I am going to respond to. Before that, I want to emphasis that I am still playing devil's advocate here.

Joe has two very insightful comments, regarding the just hard code everything and don't provide any admin interface for the parameters:

When you're making software that will be used by more than one customer, you can't hardcode these things in.


Again, why not? Why can't Company A use the same software as Company B and A wants to give 30% discount when amount is over $10K whereas B wants to give 20% when it's over $15K?
Why is that so hard to expose? It's just a matter a validation from the admin UI.

There is obviously no technical reason to do that, right?


Well, there is one good reason to avoid this at all costs. It just doesn't work when you have any significant amount of rules. And by that, I am talking anything over two dozens or so.

Let us consider what the implications of such a system would be when talking about a system with any kind of reasonable complexity.

The cost of adding a rule has gone up from a simple "add a class" to creating UI, validating values, saving values, adding to the current UI, loading parameters from persistence storage. This translate to moving from twenty minutes task (including testing) to much more complex endeavor. Consider a rule that should give you discount based on geographical location, you need to provide a way to select that. For that matter, you now need to have multi instance rules, where you need to have the same rule bound to different parameters.

Are you willing to estimate the cost now? It is an order of magnitude or two more complex.

Now, let us say that we have solved the problem in some manner. It is not a hard problem to solve, admittedly. We are still left with operational issues that we have to deal with. How are we going to educate the ops team about all the rules? So far I have chosen a very simple set of rules to show, but real business rules are nothing trivial.

Then, we have UI issues, how are we going to show the ops team the set of rules that they can edit? How are we going to represent hundreds and thousands of rules in a meaningful fashion?

My answer is very simple. Don't even try. Instead of trying so hard to cut developers out of the loop, start from assuming that there will be a developer along the way. Now you need to optimize the hell out of this approach.

Remember, we aren't talking about a system that has a very small set of rules, we are talking about a very large set of them. A competitive advantage is how fast we can go from a business requirement to that behavior running in production.

Take into account that a lot of the changes in the system are not just parameters changes, let us take example of just a few business rules that come up as things that the business wants to do. This is not in design phase. This is when the system is on the air:

  • A customer shopping on his birthday gets a 5% discount
  • A preferred customer that has been with us for over a year gets three [product name] for the price of one for this fall.

Again, pre planning for this might give you a way to deal with those (if you thought about that scenario), but even so, you are going to incur a much higher cost at the system implementation phase. Pushing the changes to code makes the implementation much easier, and the ability to modify the system at a later date is greatly improved, because you already built your system around the concept of dynamically changing environment.

But, as Joe said, this doesn't really work if you have more than one customer. It actually does, in my experience. There are a lot of system out there that have a dedicate person for their care, and giving someone a three hours course in how to do this kind of thing is fairly easy (with the requirement that they can program in C# or VB.Net, which is not inconceivable demand).

If this is still not something that you can do, put a DSL in place. A DSL script is much easier to work with for business oriented stuff, and it incur about the same cost from design and implementation view. However, deployment is ever so much easier, since you are deploying a single script, instead of a dll. You can even provide in app UI to do this, if you really wants.

In short, consider the scenario that I am describing, and oft changing environment with a lot of rules. If you have an opinion on how stupid this is, please provide that opinion within this given context.

More posts in "JFHCI" series:

  1. (27 Aug 2008) Quote of the Day
  2. (22 Aug 2008) Considering Scale
  3. (22 Aug 2008) The evil that is configuration