How to deal with exceptions to business rules?

Question

I have been given a file with several records. I have also been given business rules that determine how to process those records and produce an output file. The business rules are relatively simple:

1. If record is of type A, use methodology A.
2. If record is of type B, use methodology B.

However my client emailed me with a problem: There is one "special" record in the file. It's a type A record, but it needs to be processed with methodology B.

How does one deal with these exceptions to business rules? Some options I have thought of so far:

1. Hard-code the exception into the software: if record.id == "some_id" && record.value == 123.45 then methodology B.
2. Manipulate the file by hand, run the program, and then correct the output by hand.

My coworker is astonished that I would even consider option 1. It's messy, and next year (when I have to run this process again) the file could be different. It will turn out to a nice hidden "gotcha" that could cause problems long after I forgot about the exception.

However option 1 is easier than option 2, and if the exception to the rule stays the same for next year, I won't have to even think about it. It's already been handled. Besides, it's easy to change if I need to change it later.

How do I deal with random exceptions to business rules?

EDIT:

This is very targeted software - written to specifically do one job for one client.

Answer 1

Exceptions to business rules are generally not exceptions -- they are almost always simply more rules. So, the first thing I'd do in this case is ask WHY this particular record is an A but gets treated as a B. Where and how is that decision recorded?

If the answer is that it's recorded outside of the data that your process has access to, then the question is how best to add it to the data that your process has access.

What's the best way to give your process access to the decision will depend upon your particular situation. Others have suggested having it done as a command line argument, that will work, I generally prefer config files myself, but that's going to be up to you and your circumstances, you may just be able to query a database or webservice...

Answer 2

3. Build an override option into the program, where you can (optionally) explicitly specify a rule set for a certain processing job instead of having the program decide automatically.

Answer 3

If you are guaranteed that there will be exactly one of of the "special" records and that it can be identified easily (i.e., by its id in your example), option 1 is just fine. Don't hard-code the record ID into the program; accept an optional value from the command line or whatever way your environment lets you specify these things:

% process-records --special-id 12345 < infile > outfile

This means your client can change its behavior by the way it's invoked and you don't have to maintain multiple versions across years.

Answer 4

Your coworker is absolutely correct. Choosing Option 1 is a sign of a programmer that has not spend one minute maintaining someone else code and does not care about the likes of technical debt and future maintenance of the code base.

Its just a simple program that is needed to process the input data and create correct data for input into your main program. As the "exception" changes (as it will), your simple program that deals with is can just be updated. This could be a person with Excel, a Perl script or real program, depending how often it is done and and how complex it is. As @jmoreno points out - it is unlikely to be an exception, so as the business rules become clear, the main program can be modified to accommodate them.

(Warning - the 2 four letter words "just" and "simple" - might be worth exploring further)