Duane M Moody
Failure was not an option where I learned to make decisions.
I build software the same way.
Principal-level engineering, system design, and technical leadership for teams that cannot afford fragile systems.
The United States Coast Guard, the fire service, airport rescue, and paramedicine formed the standard. That is where I learned to decide under pressure, what failure actually looks like, why training and preparation are part of the system, and how you account for the bad day before it arrives.
Healthcare, lending, financial systems, and money movement are where that standard was refined. The domain changed. The consequences changed. The underlying discipline did not. Software was already part of the first world. I started building tools in Aircraft Rescue and Firefighting because the operation needed them, and it became the way I carried the same discipline into larger systems.
That is still how I build: understand the operation, assume the bad day will come, and design the system to remain correct when it does.
Good systems are built on good decisions.
Papers for finished thinking. Notes for captured thinking.
Perspective
What I believe about building software
- Most engineering problems are not technical. They are decision problems.
- Architecture is not documentation. It is commitment.
- Simplicity is not the absence of complexity. It is the result of understanding.
- Systems fail where tradeoffs were avoided, not where constraints existed.
Experience
My career in software began inside the operation, not outside it. I was building systems for problems I understood firsthand before software became the career itself.
Over twenty-five years, the boundary kept expanding. What changed most was not the technology. It was the consequence of the decisions.
- 01
Operation
Understand the work.
- 02
Systems
Expand the boundary.
- 03
Consequence
Own what follows.
- 04
Judgment
Decide what matters.
Selected Work
Selected Work reflects systems built under real constraints, where correctness, reliability, and clarity were not optional.
Loan Origination and Decision Systems
At Renew Financial, I worked across a 27-application lending ecosystem where eligibility depended on property, tax, geographic, financial, and regulatory data. Decision sequencing eliminated ineligible applications before unnecessary paid lookups, reducing average external-data cost from roughly $25 to about $11.
Geographic Compliance and Tax Systems
I built systems that combined parcel, assessor, tax, census, and geographic-boundary data to determine which rules applied to a property. The difficult part was turning inconsistent public records and overlapping jurisdictions into deterministic answers that lending and servicing systems could rely on.
Decision Engines and State Machines
I built decision engines and state models where correctness depended on making allowed transitions explicit rather than scattering business rules across application code. In financial workflows, that also meant reasoning about retries, partial progress, repeated messages, and whether the same operation could safely happen again.
ACH Processing Systems
At Jack Henry, I work across ACH processing involving files, batches, entries and addenda, RDFI and ODFI responsibilities, returns, posting, warehousing, and file generation. The architectural focus is identity, explicit lifecycle, safe retries, transactional boundaries, and recovery when distributed processing stops between durable steps.
Personal Finance Aggregation and Enrichment
At Jack Henry, I worked on financial-data aggregation and enrichment that normalized inconsistent upstream transactions into a consistent domain model, then applied merchant normalization, categorization, metadata, and other interpretation. Historical reprocessing allowed improved rules and mappings to be applied to past data without compromising current ingestion.
Featured writing
Papers
- Seniority Is Pattern Recognition Under PressureFeaturedThe real value of senior engineering leadership is recognizing instability before everyone else is forced to.
- The Illusion of VelocityLatestWhen movement replaces progress—why busy delivery cultures quietly erode the conditions for sustainable speed.
Notes
- Systems Tell You When They Are FailingLatestFailures that feel sudden are usually preceded by signals that were ignored.
- Interfaces Are Where Systems BreakMost failures do not occur inside a component. They occur at the boundary between them.
- Determinism Is Not OptionalIf the same input does not produce the same result, the system cannot be trusted.
I founded XRiley to bring that approach to architecture, technical leadership, modernization, and software delivery for organizations dealing with systems where fragility has real consequences.