Legacy system risk
In the late 1970s, I landed my first real programming job.
The title alone sounded intimidating: Automobile Financing System.
At the time, I had no idea how long the software would live—or how much responsibility it would quietly assume. I was focused on solving a very immediate problem with the tools available to me, on machines that were unimaginably slow by today’s standards, with memory measured in kilobytes rather than gigabytes.
I didn’t think of what I was building as “infrastructure.”
I thought of it as a clever solution that worked.
The system processed automobile loans—terms, interest, payments, edge cases—using algorithms that had to be precise, efficient, and correct. There was no margin for error. Mistakes didn’t show up as abstractions; they showed up as real money, real customers, and real consequences.
What I couldn’t see then—but can see clearly now—is how often systems like this quietly outlive their original context.
They begin as small-team solutions.
They prove themselves by working.
They earn trust through reliability.
And before anyone notices, they become mission-critical.
The Quiet Risk Emerges
From the outside, systems like this appear stable. They run. They produce results. They don’t demand attention.
But internally, they often rely on:
Deeply embedded business logic
Algorithms few people fully understand
Knowledge concentrated in the heads of a shrinking number of individuals
None of that feels dangerous at first—especially when the system continues to perform.
And that is precisely how silent risk accumulates.
The Story of My First Programming Job
A 20 year old boy. A blackboard. A chair. A Wang computer. A challenge.
A challenge: Write a program to engineer a wooden arch support for a vaulted ceiling church. If I could do it, I would have the job. Maybe.
Bill Putnam and Bill Pardini had a company called Data Consultants, Inc. And they wanted a junior program to create an Automobile Finance System for $2 per hour.
This small company produced software in a few variants of Basic as many small companies did in the 1970s.

They had Wang computers.
It’s 1976 or 1977 and in walks this kid.
Wet behind the ears. No computer experience except in school. And his only work experience was washing dishes and selling products at Weinstock’s and Radio Shack.
What can he do? Sit him down at a Wang Computer and give him an impossible task.
Well, that kid was me, and I wanted to be an acoustical engineer designing music halls and musical instruments. I was precocious and competitive at math, had a background in physics and engineering statics, and strength of materials. And I was a natural with computers.
So, they asked me to write a Basic program on the Wang that would use finite element analysis to design a wooden arch for a large church sanctuary. I succeeded.
So, I was the kid for the job at $2 per hour. And I had the persistence to meet the challenge.
Meet My Computer – The Processor Technology SOL Terminal Computer!

And they had Processor Technology SOL Terminal Computers
Building the Automobile Finance System
To Bill Putnam I was just an annoying kid. Or so he wanted me to believe. Yet he always seemed cynically pleasant, positive, and intrigued. And I thought I had two of the greatest bosses.
Bill Pardini exuded excitement over the project. Contagious excitement. This new system we would build would change the car sales industry. Of course, all CEOs say that. But it kind of happened.
Eventually, the company split into two, both fighting legal battles over who owned the system. It made some people rich. Just not me. But it made me rich in happiness. And it started me on a 40 to 50 year career I would cherish.
This Auto Financing and Leasing System
Bill Pardini showed me a hand-held device. It looked like an early cellular phone that hadn’t been invented yet. Salespeople used it to perform loan calculations.
I would be creating a desktop program to outperform it and let salespeople work with customers to put together an ideal car loan and print a bank contract afterward.
And it would make automobiles, RVs, and other vehicles sell like hotcakes.
I developed the program in Northstar Basic, an interpreted programming language that ran efficiently in 11K of memory where my would be saved onto a 5 1/4 inch floppy disk holding only 90k of disk space. The CPU was an Intel 8080 running at 1 MHz.
Blazing fast. Right? Stop laughing! Back then it was lightning fast.
I organized all the fields on the 64×16 character TV screen/video game screen for quick editing. Fill in all the numbers you have handy. The automobile price. The down payment. The interest rate. The term of the loan. The type of insurance desired.
Now leave out any number, and the computer would calculate the missing field immediately.
Ok. So a customer would come into a shop to buy an expensive luxury car used for around $4,000. (This was around 1977). He had $450 to put down and could afford to pay $250 per month. How long would it take to pay it off if the interest were, hmm. 10%?
Is that add-on interest or APR? Wow. Um. Let’s say it’s APR. How long would it take? Ok. What if we make it add-on. What would the equivalent Add-on rate be? Isn’t that a little sleazy? Ok. Go back to APR. What insurance should we get if we want to keep the loan under 4 years?
The point is you could calculate anything. Then put in a BofA or Wells Fargo contract, press a button, and print off the contract.
The Secret Sauce – Newton-Raphson Iteration
Of course, not every calculation was straight forward. In fact, they could not be calculated algebraically at all. I used something called a Newton-Raphson iteration–a fast converging iteration that would produce highly accurate calculations in no time. And most programmers did not know how to do that.
But I did. I went to a friend’s engineering office and rewrote his flagpole footing calculation program on an Apple II+ in Apple’s Basic. Instead of taking several minutes and producing questionable accuracy to perhaps 1 digit past the decimal point, He had his answer in 1 1/2 seconds several digits past the decimal point.
He had to check the calculations many times over before he would believe the program worked. But it worked flawlessly.
About 40 years later, I learned that the folks at Data Consultants had rewritten my earlier auto financing and leasing systems for newer computers but had strictly left alone the algorithms I set up in the 1970s as they worked and nobody wanted to change that.
Sadly, my friend and boss, Bill Pardini, passed away from cancer, and I found out when I hoped to visit him at DCI. I recently learned that Bill’s brother took over as CEO, and for that reason, I hope to visit there one day when I set aside the time.
Newton-Raphson Iteration
\(x_{n+1} = x_n – {f(x_n) \over f'(x_n)}\)
So, I rewrote each calculation into a form where some function of x=0. From that, I could perform a Newton-Raphson iteration using the formula above. This produced highly accurate results almost immediately.
Printing Forward and Backwards
We had Xerox Diablo star-wheel printers with contracts using carbon sheets for copies. So, I developed the subroutines for printing forward and backwards and specified where the fields were on the contract so a person could load the contract into the printer and tell the computer to print, and all the appropriate fields would be filled in automatically.
The Vanishing Customer Demo – POOF!
Bill Pardini was excited and got ready to give the first demonstration of the program to a prospective customer. But somehow, he accidentally deleted both the originally saved program AND its backups.
He was crushed. And for some reason I thought I could just take home the computer and remake it from scratch overnight all over again.
And, well, I was right. I brought the computer back the following morning, and everything was working again. I did not remember the program verbatim, but I remembered the logic and was able to reconstruct it again, test it, and have it ready for the demo the following morning.
Not bad for a $2/hour kid programmer, huh?
Pardini’s Continued Success
I would not want to take credit for Bill Pardini’s success because ultimately he was the one who came up with the idea of doing this program and provided me all the foundational math computations other than my turning them around and doing a Newton-Raphson iteration to do the calculations backwards and upside-down in every which-way. And he was the business genius behind selling this program to so many companies in the area.
With that program quickly becoming popular, he asked me to create a similar program for automobile leasing. And as it was essentially the same as the automobile financing program, the work was fairly trivial. It was more of a customization than the start of a new program.
Newsletter
Please sign up for my newsletter if you wish to be updated!
Thanks!
