Business Tech: Parametrics

It's the early nineties. I've been tasked with fixing a truly terrible system at a small division of a big company. When I say terrible, I mean that the week-ending reports took eight days to run. Programs crashing. Different answers coming from the same data. I can still feel the pain just by thinking about it.

As I'm digging into the problems —weeks into the cycle of fix-test-fix — and in the shambles of a system before me, I spot a thing of beauty. The core of this behemoth was a small, tight, well-designed parametric system.

Call the Parametrics!

At that moment, I was transported back to a conversation I'd once had with my brother. Bennett said to me, "If you've ever written something and then put your hands behind your head and leaned back to marvel at how cool it is, you've written something too complicated."

Someone, early in the development of this system, wrote something marvelous. The disaster came as other people, with little or no understanding of the infrastructure, trod all over it. There are two lessons we can learn here. Either (A) don't ever do anything clever or unusual, or (B) document things and invest in training your staff.

I've always favored plan B.

In the end, with two additional full-time programmers hired and an unmentionable amount of consulting money spent, the system worked... more or less. Some of what we did to fix it came down to stripping away the kludges and restoring the core design. The process was akin to rebuilding a classic car. What you ended up with wasn't what rolled off the assembly lines, but rather an homage to that original vehicle. Some parts the same, some parts newer and shinier, all of it covered with a coat of paint designed to make the results look uniform and consistent.

That marvelous parametric engine, in the hands of people who knew what it was, made the code versatile and responsive to business needs.

The Million Program March

In another job, we had two teams. Team Alpha was solving business problems quickly. Team Beta didn't show the same level of results. I was on Team Beta. More than that, I was the captain of Team Beta.

What was the difference between these two teams? Team Alpha wrote (mostly cut&pasted) an average of one new program per calendar day. Team Beta fixed the wreckage created by Team Alpha. We took fifteen versions of the same program and made one parametric version. We fixed FOR I = 1 TO DCOUNT(REC,@AM) so it didn't require the DCOUNT to recalculate for each of the thousand lines in the record. We killed off single letter variables like they were mortal enemies.

Why clean up? After all, computer hardware is getting cheap and programmers are relatively expensive. Just throw some Mflops at the problem, right? Thing is, as my friend Patrick once said, "Code is a mortgage on your soul." Three hundred and sixty-five new programs a year (give or take) made every change a nightmare to research. It made regression testing too time expensive. Without Team Beta, the system would have become the biggest stumbling block to the future success of the company.

1K-Foot View

Parametrics are hard because you need to understand the mission. The thousand-foot view is required. Otherwise, you are randomly making some things parameters and not others. Let's look at a retail system, for example.

Prices fluctuate over time, but that's not a good place for parameters because it can be managed at the SKU or product level. However, sales affect categories, which means that building parameters which identify which items should be adjusted by which sales offers at which times, and so on. That's a good place for parameter logic. So, prices are pulled from INVENTORY records or a PRICE table, but sales are computed based on which settings are in play.

Selling men's shirts for Father's Day is a matter of adding a discount for each category which contains men's shirts. Set 30% for MENS-CASUAL, MENS-DRESS, MENS-SPORTY, and 0% for everything else. New holiday, new answers for the same parameters. No changes to the standard prices required. Nothing to change in the programming because the programs are parametric.

Here's the fun part. If we manage this by parameters and not by code, we can reap some sizzling secondary benefits. Your sales parameters can be used to tweak your restock logic so that you make sure that stores in your chain have the goods you are about to put on sale. Reporting can isolate sale-vs.-non-sale data because you have categories and time-frames. You can see which stores benefit from which sales. You can then target local events to different stores based on what brings in the crowd for each store.

People in midtown might buy differently than people in the suburbs. Or, maybe they don't. At least when it comes to your mix of products. Now you'll have the data needed to see which way your business works.

Code Example

The core of this idea is simple. Replace this

read INV.REC from INVENTORY.FILE, INV.ID then
   PRICE = INV.REC<16>
end

with this.

read INV.REC from INVENTORY.FILE, INV.ID then
   PRICE = INV.REC<16>
   locate(INV.REC<24>,SALES.CATEGORIES,1,CPOS) then
   PRICE = int((100-SALES.CATEGORIES<2,CPOS>) * PRICE/100)
end
end

What's happening on line 101? The SALES.CATEGORIES record has a list of category names ( MENS-CASUAL, MENS-DRESS, MENS-SPORTY,WOMENS-CASUAL,WOMENS-DRESS, WOMENS-SPORTY ) in attribute one. There's a corresponding discount (20,20,20,0,0,0) in attribute two. When we want to give a different discount, we tweak the SALES.CATEGORIES record. For example, if we want to discount all "SPORTY" instead of all "MENS" we can set attribute two to " 0,0,15,0,0,15 ."

The Takeaway

You can't create a good parametric system without understanding the underlying business logic. Knowing what today's rules are is not enough. You have to have some sense of how they will morph over time. While including the subject-experts in your company is always a good idea, they supplement your understanding; they don't replace the need for you to know.

Featured:

May/Jun 2016