Do you remember that long list of requirements that defined the project to create this application or that? What these are was a definition of “reality” — as it was understood at the time — for the organization.
There’s a well-known story, that of a major insurance company and its payroll. Back in the mid-1800s, when pay was in cash, the company avoided handling coins by keeping track of amounts less than a dollar, rounding up to the next dollar in terms of payment at 51¢, and keeping track of amounts overpaid or owing between pay weeks. This, in turn, was carried over into their accounting machine-driven payroll, and finally into their home-grown payroll application.
A practice such as this, which wasn’t needed once pay was issued as a cheque (and later, as a direct bank deposit), hung on for years after its time partly because, for anyone at the company, this was reality — and partly because, at any point in time, any changes kept the requirement to “round up and down between periods” on the table.
As a result, long after others had outsourced payroll, the company hung on, claiming it was “different”. It took an outside intervention to finally eliminate the old reality and remove this requirement.
Now, consider banking systems. One major bank now provides electronic versions of the statements for chequing and savings accounts, rather than mailing these to customers.
Their line of credit accounts — which to the customer look just like any other bank account (and are often used that way, with a chequebook or with Internet banking transfers) — do not offer an electronic statement. Why?
Lines of credit are built off the “loans” application, whereas chequing and savings accounts are built off the “core banking” application.
Note that there is nothing about a line of credit that is different from overdraft capabilities on a chequing account (where there is a negative balance and a maximum negative limit, and an interest assessment made rather than paid), except for the “old reality” that the original lines of credit were loans.
A third form of “old reality” is when a system’s actions now deviate from the actual work practices.
This shows up as manual steps, bridges built from spreadsheets or rekeying of data, etc.
There are insurance systems still in use dating back to batch processing on mainframes, where transactions were keypunched — and certain types of data were converted from alphanumeric characters, such as turning the state code for South Carolina (SC) into a number (e.g. 29) so that the keypuncher could get additional speed by staying on the numeric keypad.
Here we are, fifty years later, with elaborate training programs run for new staff, and aide memoires stuck around each PC screen, to remind people of the conversations. What once was a productivity aid is now a drain.
This is yet another reason why software should not be considered to have an indefinite shelf life and endlessly modified, but rather be expired periodically and replaced.
It allows for old realities to be expunged and replaced with software that models today, not yesterday.
Vendors do this: consider Windows 8′s Metro interface, a complete overhaul of a user experience that hasn’t materially changed since Windows 95. If Microsoft can do it, you can too. You have nothing but old realities that have outlived their usefulness to lose.