Daniel J. Dick

How Legacy Business Systems Become Institutional Truth

The automobile financing system didn’t end with loan calculations.

Once money starts moving, accounting follows.

This article is part of the series When Systems Outlive Their Designers, exploring how long-lived systems quietly become mission-critical—and risky.

What began as a focused application to calculate terms, payments, and balances eventually required a second layer—one responsible for translating operational transactions into accounting reality. That second system would come to be known, informally, as Son of Automobile Financing Accounting.

At the time, this felt like a natural extension. The original system worked. The logic was sound. The business trusted it. Accounting needed the numbers, and the fastest way to provide them was to build directly on what already existed.

I didn’t think of this as creating a dependency.
I thought of it as efficiency.

But accounting systems have a peculiar gravity. Once they are trusted, they become authoritative. Once they become authoritative, they become difficult to challenge. And once they are difficult to challenge, they often outlive both the people who built them and the assumptions they were based on.

That is how business logic quietly becomes institutional truth.

---

Where Risk Quietly Deepens

Accounting systems don’t merely report what happened.
They define what is believed to have happened.

When those systems are tightly coupled to legacy logic—especially logic few people fully understand—the cost of change rises quickly. Rewrites become dangerous. Corrections become political. And disaster recovery becomes less about restoration and more about reconstruction.

None of this feels urgent—until it is.

---

A 22 year old programmer. Experienced. Wiser. An Recreation Vehicle. A kind, older boss. A cigar. A chair. A Vector Graphics Computer. And a vision.

Other Related Jobs – Pat Paris

After building out Bill Pardini’s Automobile leasing and financing systems, I developed business applications for Pat Paris. And I earned my first computer–a Vector Graphics 8080 system as pictured above.

I created most of the standard business programs–GL/AP/AR/PR, Inventory, and I cannot remember what else–all in Business Basic.

A man in his sixties, Pat Paris breathed joy, optimism, and cigar smoke into the RV which became my office outside his house as he looked over my shoulder with excitement to see the progress of his projects.

International Peripheral Systems – Payroll, Order Entry, and Rubber Band Fights

Break time. Peaceful morning. No yelling heard through a closed door at a salesperson by the boss.

It’s time. Whewwww tick! My coworker feels a sharp sting in his neck as the boss’ daughter gives her daily rebuke, “You guys are so immature!” A rubber band fight has broken out again.

Honor compelled me to defend my team. We were all crack shots. Break ended and there were no lingering after-the-ceasefire shots. Clay was at the soldiering gun. Others took their work stations. I programmed. And the bookkeeper and boss’ daughter were safe.

Back to Work

I felt as if I were the only employee the boss never yelled at. I liked him, and he liked me. My primary duty was to build their order entry system. But when they needed some modifications to their payroll system, I accomplished that, too.

The bookkeeper and boss’ daughter argued, “I don’t think that will work.” “Yes it will.” “Aren’t you supposed to do the calculation this way?” As smart as these ladies were, they knew whatever I did worked. They just needed to figure out how.

And I thought to myself how strange it was that algebra could be a controversial subject. Yet, that’s how people learn. I was OK with that and encouraged it here and when I tutored others in math.

International Peripheral Systems was owned or run by Robert Murray. His company assembled Xerox Diablo printers like the ones used at DCI. And my job was to modify or customize the Payroll program and create an Order Entry system for the company.

From Intel 8080 to Zilog Z80 and Farm Accounting at Argos

Argos – Farm Accounting and Irrigation

In 1979, I went to work for Argos. And like DCI or Data Consultants, Argos still exists! My boss, Alan, an Agriculture PhD, and his wife, a Stanford mathematician introduced me to Gary, my new senior programmer who would mentor me.

Gary and I would develop a Farm Accounting system.

Argos did not use normal computing languages like Basic or Cobol. We used an in-house programming language called “Argol”. Not “Algol”. But “Argol”.

The Argol compiler was barely more than an assembler. In fact, I am not sure it had the sophistication of a good Macro Assembler. But Argol was fast. And it worked with a report writer, a database, and a screen-writer.

Gary and I plodded away developing one accounting program after another until a PhD in Agricultural Irrigation joined the company, And the boss, Alan, wanted me to help him develop an Irrigation Scheduling system.

From this gentleman, I learned a great deal about irrigation, evaporation, types of irrigation, and more. We made progress until we conflicted over what might be called “data normalization” or “single source of truth”.

Rather than negotiating to a common understanding, it became a power struggle and brandishing of qualifications. And at that point, I did not feel we should continue working together.

I wished them the best success and went to work with Fresno Unified School Districts Data Processing.

I Noticed Something…

Early in my career, I noticed something. Let me correct that. I didn’t notice it back when I was a kid because there was nothing to notice yet.

I noticed these things about my early career. Things that would repeat themselves throughout my career:

• I learn.
• I start something new.

Perhaps I should say it better. I’ve been crazy curious about technology since childhood. And I will always innovate actively seeing a need, meeting it, and automating it. I may create a company, a department, a sophisticated system, or a goofy kluge that somehow works and grows into all of the other things magically over time.

• An automobile financing system.
• A farm accounting system.
• An order entry system.
• Engineering programs for which no good solution previously existed.
• A university computer science technical environment.
• A substitute teacher assignment system.
• A project plan to move NASA scientists from VMS to Unix.
• An Internal Support Team for a Database company.
• A security management system for that company.
• An applied research department and an internal security team for another database company.
• An e-support system and team.
• An IT, support, and QA department for a successful startup.
• A pharmacy encounters system for a PBM.

Did I create these alone? No. I enjoy being a team player. But if I must work alone, I will.