Why I Build
Forty years of making tools. A few things I've learned about why I keep doing it — and what "building" actually means when the problems are this complex.
There is a moment in every project where the abstraction breaks and you are face-to-face with the actual problem.
In 1984, building RAMCAP, that moment arrived when I realized that 230 asset classes fit into a correlation matrix but a correlation matrix does not tell you what to do. The math was right. The decision was still hard. The tool had to bridge both.
That gap — between accurate model and actionable decision — is still what I build toward. It has not closed in forty years. It may not close. But the tools we have for navigating it keep improving.
When I teach (and I did, for four years at the College for Financial Planning in the late 1980s), the question students most often asked was some version of: what model should I use?
I would tell them: the model is the least interesting part of the problem. The interesting part is what assumptions you are hiding inside it, and whether the person using it knows those assumptions are there.
This is still true. Today’s students are asking the same question about AI models instead of financial models, but the structure of the problem is identical. Every model encodes assumptions. Most users cannot see them. The builder’s job is to make the assumptions legible — or at least, honest.
RAMCAP was the first thing I built that other people used to make real decisions. That changes you.
You start thinking about what happens when you are wrong. Not in a theoretical sense — in the sense of: someone is looking at this output and forming a belief about the world, and that belief will lead to an action with consequences. You want the software to earn that trust.
That’s a different standard than “does it compile” or even “does it produce accurate results.” It’s a standard about the quality of the decision it enables.
CoinRoc is, in one reading, a crypto trading tool. In another reading — the one I find more interesting — it is an attempt to answer the question: can you rate a strategy’s quality without knowing whether it will be profitable?
The answer, I believe, is yes. A strategy can be good or bad independent of recent returns. It can be robust or fragile. It can be suited to a market regime or badly matched to one. These are measurable properties, if you choose the right measurement framework.
Fuzzy logic is that framework. Not because it is fashionable (it is not, particularly) but because it is honest about uncertainty in a way that crisp rules and point estimates are not.
People sometimes ask me why I keep starting new things instead of scaling one thing.
I have tried to scale. Sometimes it works. More often, what I find is that the interesting problem moves on before the organization does. And I would rather follow the interesting problem.
That might be a rationalization. It is also, I think, accurate.
I build because the gap between the model and the decision is still there, and still matters, and the tools for closing it keep getting better. Every time they improve, there is a new version of the same problem worth working on.
That is enough. That has always been enough.