S is for Separation of concepts

This year, for the A to Z Blogging Challenge I'm posting alphabetically on topics related to software development...

Many years ago, when I was a fresh-faced programmer, I worked on a replacement for an old payroll system.

In this old system, employees were all flagged with a "pay type", which was either "M" or "W".

"M" type employees were paid monthly on a salary. Each month they received one twelfth of the annual amount for their pay grade, and their salary was paid straight into their bank account.

"W" type employees, by contrast, submitted timesheets each week from which their pay was calculated on an hourly rate, and each Friday they got an envelope with cash in it.

This innocuous "pay type" rolled three entirely distinct and separate concepts into one field: How often you get paid, how your pay is calculated, and how it gets paid out.

At the time, this probably seemed like an obvious and direct translation of the business need into computer code. Clean and simple.

In more enlightened times, this approach is a Very Bad Thing.

Sadly, though, this is a very easy trap for business users to fall in to. They are used to expressing "what is", and in their minds, two or three independent concepts easily get intertwined through unvarying usage. They might even say, "But weekly paid means time sheets, that's just how it is." Or the habit of thought might be so ingrained that they don't even articulate it. It's an unspoken, unwritten rule.

Worse, as a software developer it's easy to get intimidated into accepting this state of affairs. But your job, as a software developer, is to get your surgical scalpel out and separate these conjoined twins.

In this example, the "pay type" in the new payroll system became a "pay cycle" field whose only job was to determine when people got paid. The method of calculating pay was determined by which pay scale you were assigned to, and how you got paid was an entirely separate "pay method" field.

The concepts got separated.

The benefits were immediate.

Manual workers could now be paid into their bank accounts, which used to be the preserve of white collar staff. We could easily accommodate new agreements with different pay cycles, like different groups being paid on different days of the month, or paid every two or four weeks rather than weekly. And it became possible to mix payment calculations so that salaried employees could, on occasion, submit timesheets for overtime, or weekly employees whose agreement included a fixed element on top of the timesheet hours.

Separating concepts like this gives you enormous flexibility. When you go into Subway for a sandwich, they don't say you can only have chicken on toasted whole wheat, or ham on white. They allow you to mix and match filling, topping, bread etc. to suit your taste.

And the killer argument for separating out concepts like this: divide and conquer! It's almost always easier to program that way!

Who can possibly say "no" to that?