About

Harmonic Design is the work of William Anderson — a software architect, engineering leader, and framework author with nearly twenty years of experience building systems that have to survive contact with reality.


William Anderson

William Anderson

Software architect, engineering leader, author of Harmonic Design

Background

I grew up in rural poverty in Arkansas with parents who struggled with addiction. The home was unstable — I moved about thirty times before I was fifteen, then left home and stayed with friends until I finished high school and went to college. I didn’t have my own computer until then, but I stumbled into software at fourteen — writing C++ and playing MUDs at the public library. I didn’t know yet that it would become a career. It was just the first thing that made sense to me.

I mention this not for sympathy but because it matters. Growing up in chaos gives you a sensitivity to structure — to what holds together under stress and what doesn’t. It shapes the problems you notice and the problems you choose to solve. The conviction that systems should be built to endure, that complexity should serve people rather than burden them, that opportunity should not depend on where you start — that didn’t come from a textbook.

Career

I discovered software engineering as a profession at twenty-two. I dropped out of college, worked, returned as an adult to finish my degree, and built my skills across every kind of organization along the way — international consulting engagements, early-stage startups, Fortune 5 enterprises. I’ve been an entrepreneur and investor. I’ve owned and operated businesses. I’ve held leadership roles, done sales, and earned my PMP certification along the way. I’ve failed spectacularly more than once. Each of those experiences taught me something about how systems work and how they break.

My industry experience spans logistics, retail, entertainment, hospitality, industrial automation, insurance, healthcare, food service, real estate, and financial services. A significant part of my career was spent on master data management — work that reinforced how critical structural discipline becomes when data flows across system boundaries at scale. I have taught architecture and project management courses, and spoken at events like Tulsa TechFest and various .NET user groups.

Most recently I joined a large retailer as a principal engineer, where I work with talented people of high integrity every day and solve problems at considerable scale.

Practice

About thirteen years ago I encountered Juval Löwy’s IDesign methodology — what this framework calls Volatility-Based Decomposition. The idea was straightforward: organize systems around anticipated change rather than current functionality. I applied it and never looked back. It changed how I thought about architecture, component boundaries, and why some systems absorb change gracefully while others fracture under it.

I worked with Löwy as a consultant with IDesign for many years, learning firsthand about identifying volatility, architecting systems, managing projects from architectural structure, and what it means to practice software engineering as a profession. As I kept applying these principles, I saw them echo in other disciplines — interface design, testing, project planning, organizational structure. The recognition that these were not separate insights but readings of the same underlying structural map is what Harmonic Design articulates.

Convictions

Developing software shouldn’t have to be hard. The complexity should live in the problem domain, not in the tools and processes we impose on ourselves. When the structure is right, engineers can focus on the work that matters — and helping them get there is what I care about most — developer experience, mentorship, the craft of building well-structured software. That is what Harmonic Design is for.

I am equally passionate about AI. It has genuine potential to create opportunity and free people to do work that actually matters to humans. That said, I hold no illusions about what current models are. Large language models are sophisticated pattern engines, not thinking machines. They don’t understand what they produce and they can’t reason about novel problems from first principles. But they are extraordinarily useful tools — and useful tools change the world regardless of whether they pass a philosophy exam.

At the end of the day, what drives all of this — the framework, the engineering, the teaching — is a belief that we can move forward as a society while being better to each other. I live in Fort Smith, Arkansas with my wife Sarah, our three children — Fox, Ben, and Chloe — our dog Bosco, and six cats. They are the reason I care about building things that last.