I’m big on documentation. And I’m a programmer, believe it or not. I’m a flowchartin’ fool, and I love to add logic tables to my work. What’s a logic table? I’m not sure why it’s not more common than it is, because it sure beats a lot of the excuse for documentation I’ve seen. And it’s so readable that you can even show it to the users and after a little guidance, they’re able to figure it out. It’s a great tool, and is very under utilized.
Here’s a sample. Let’s say you’re coding a very complex series of “if” statements. It works. And you understand it. Until two or three weeks go by, and you have to explain to the users why a report line is showing things the way it is. You try to explain to the user why it reflects their stinking business rule. You even resort to looking at the code, and you get lost in the complexity. Geez, it looked so simple last week.
Okay, here we go–this is a way to capture the business rules, and the program logic at the same time. It’s basically a table with decision questions as column headers, and actions for the rows.
Here’s the business logic: if a student is a senior, he is allowed to take Physics II, but only if he’s a senior. Here’s how it looks in the table.
Notice that every combination of logic for Junior and Senior vs. the two level of Physics are taken care of. No ambiguity. Now, let’s add a little more complexity. A Junior can get into Physics II if he has a letter from his adivsor.
With a big table (many decisions), the logic gets hairy, but the with a logic table, you can make sure that every logic decision point is covered. If you try it, I think you’ll find that it makes things much clearer. And it has great value in capturing business logic.
The two dashes denote that it’s immaterial whether a Junior has a letter or not.