Equational

 I have always been a very visual thinker, I tend to think in images and feelings, and less in words. Therefore having just reread my  Why Use Arrows and PowerPoint to Express Software Designs?  blog, which is all about using visual props to help you design systems, and remembering how ineffective these visual representations were in helping me share my ideas, I find myself needing to accept that my carefully crafted "invariants as drawings" approach have really mostly only helped me, and definitely were unable to express enough to others to drive a software development! The bright side of this story, is as much as at Actant, as later a Elevence, we had the insights to center development around a DSL. The team then having the freedom to express the needed properties in the DSL, I having the freedom to ask for something non-obvious by describing the expected behaviors, not the invariants, and especially not as visual projections that lack reading instructions. The bigger s...

Building advanced software systems by trial and error is a fast track to bankruptcy. Today, the cost of generating code has plummeted, but the cost of ensuring trust and verifiability has skyrocketed. To survive this economic squeeze, we can no longer rely on outdated, informal development cycles. Over the last few weeks, I have documented the mechanics, psychology, and processes behind a "zero-fail" methodology I have used for over fifteen years. I call it High-Performance Software Engineering . This post serves as your router and introduction to the series. It breaks down the six foundational pillars of this methodology and points you to the deep-dive articles that explain how to make it a reality. The Engine: A Product and DSL-Driven Process High-Performance Software Engineering completely bypasses the traditional Agile cycle of translating features into stories and stories into code. Because human translation always results in lost intent and bloated latency, we change th...

Introducing "Trusted Engineering Processes" During my CS studies, I spent two summers at the CSEM (Centre Suisse d'Electronique et de Microtechnique) , first improving their Design Rule Checker , then rewriting it. This was my first encounter with a rare breed of individuals: engineers who possess an almost pathological commitment to rigor, whose value lies not just in their raw intellect, but in the absolute predictability and safety of their methodology. Recently, in the context of blogging about how these engineers succeed , I thought it would be good to talk specifically about individuals and team formation for what I call "trusted processes," as collectively, we heavily rely on the innovation built by these individuals. It is, however, not the easiest task! In Deep Tech Servant Leader in Ten Rules , I presented team dynamics from its leadership perspective. How do we present it from a team perspective? Here things become a bit complicated. We have the follo...

In 2011, after fourteen years developing derivative market making software, I took some time for myself, and wrote a prototypal compiler for a reactive trading language. I bring this up because a reactive trading language is a DSL, and I wanted to write something about DSLs in the context of my recent writing about  High-Performance Software Engineering . Therefore I asked Gemini to rebuild something similar as my 2011 effort, with four new twists:  the introduction of profunctors (I had only monads and comonads back then),  the use of combinators to not only to parse the DSL's syntax, but also it's traced execution semantics,  a JIT approach based on working with traces, This is Python. It was F# in 2011. What you have below is Gemini's description of two days of work. And to highlight the still very toy language stage of this language. The goal is show how advanced computer science can be done very quickly in 2026. From a language design perspective, what we h...

In an earlier blog on high-performance software engineering , I noted that cruising at maximum height and speed to avoid turbulence requires depending on an experienced pilot—a deep tech servant leader. Beneath that operational framework, however, lies a practical reality: true psychological safety—an absolute necessity if you want team members to fully invest in a project—is not a natural, organic human state. It is an unnatural, synthetic environment relentlessly enforced from the top down. As a result, the project lead must act as both the evangelistic emotional booster and the team's shield against the brutal asymmetry of startup and stakeholder power dynamics. To survive the sheer, un-hedgeable fragility of a 0-to-1 build without suffering decision paralysis, the experienced pilot runs a dual-process system. They project the illusion of a "simple liquid world"—a psychological firewall that allows for rapid decision-making with cold precision—while quietly and constan...

What happens when you are building something so unprecedented that the words to describe it do not even exist yet? Standard Agile assumes product and engineering can just sit in a room, write stories, and align. But you cannot write a user story for the "new new". The vocabulary simply isn't there! If you try to push uncharted concepts through standard communication channels, the sheer friction of translation loss will kill your project. You cannot manage the unexplainable with tickets. The fix is to stop talking and start specifying. Before you build the product, you build the language . A Domain Specific Language (DSL) forces abstract, never-before-seen concepts into a rigorous grammar. It creates a structured medium for ideas that previously had nowhere to go. Once that language is defined, the engineering team's job shifts entirely. They do not need to decipher a deeply complex, uncharted business domain. Their only job is to build a compiler, the engine, that mak...

In a recent post, I outlined the mechanics of what I call " High-Performance Software Engineering ". I made the claim that failure simply isn't an option, and that treating your development process like a hedge fund, or keeping a "six-shooter" of limited fixes in your pocket, is the only way to survive extreme technology projects. But claiming a method works, and actually understanding why it works under the hood, are two different things. It is time to lift the hood a little bit. If we step back and look at this through the lens of systems engineering, specifically looking at latency, throughput, fault tolerance, and something called Little's Law , we can see exactly why this somewhat rigid approach outpaces standard agile. Here is the structural reality of why we manage to not fail. Building engines, not just features In any software process, you have "latency" (how long it takes a single idea to become delivered code) and "throughput"...

Embracing Asymmetric Risk What is the common economic theme between: Lockheed Skunk Works (1943) ( see my analysis here ) Netflix's Migration to AWS and AWS S3 Storage (later 2000s onward) High-Performance Software Engineering  (my previous post) Embracing engineering as  high-risk, high-return investment where risk is asymmetric, bad things can happen, and no less than exponential growth is expected! The key primary word is RISK ! The key secondary word is EMBRACE ! And therefore why I wrote that  High-Performance Software Engineering is like  "running your development like a hedge fund " Some history, three dimensions Let's start with the following claims:  Google invented the foundational math and architectural blueprints (GFS, MapReduce, Borg) that made massive distributed computing possible. AWS commoditized that architecture, transforming physical hardware into infinitely scalable, programmable infrastructure . Netflix pioneered the operational c...

Is failure ok? I was recently asked: " What companies have a culture where failing is ok "? I cheekily answered " None "!  The art of high-performance engineering This is the recipe I have been applying for the last fifteen years: Never f ail to achieve previously promised goals Never f ail deadline because of waiting on others Never f ail to use all your team members Never f ail to stay productive because of exhaustion Never f ail because of misalignments Never f ail because of past work no longer relevant, or past work never finished. To which mostly people say: are you kidding? There is a twist! These are extreme technology projects. Agile deconstructed An agile process typically maintains delivery drive and failure avoidance with process cycling over: Features (what we discuss with our stakeholders) Stories (what we work with) Code (what we deliver) These are primary driving efforts.  I skip the 10+ supporting efforts, such as validating, analyzing, etc. I skip ...

Sixt y years ago, Melvin E. Conway wrote: Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin E. Conway, How Do Committees Invent? (quoting from Wikipedia) How does Conway's finding affect software language design? How does one specify a language that meets the many different communication structures of one or more organizations and yet still preserve formal properties such as security and provability? How do I make a language that does not end up communicated as list of hundreds of recommended design patterns? How does one zigzag between OO, FP, and other programming approaches? How is this related to machine learning and LLMs? Recently I was asked to help on a project. My immediate response was: Tricky, knowing what I know now, I would write a DSL to produce the necessary content for the project, but we cannot afford that for this project, so no DSL. ...

Writing software that actually behaves like pure math is harder than it looks. Usually, state changes, loops, and memory quirks get in the way, turning elegant logic into a tangled mess of side effects. A modern tracing library fixes this by acting as a silent observer. It watches your program execute, sweeps away all the temporary memory junk the computer needed to do the work, and leaves behind a perfect, permanent map of how your data actually flows. By completely separating how the code runs from what the math is, you get a flawless, auditable blueprint of your system. It gives you the exact precision needed to stop fighting your language's quirks and start engineering truly smooth, reliable software. And so last year I wrote a first draft of a Python tracing library (see original https://github.com/equational/hltpy ). This code works, but fails to be elegantly re-entrent: it is tricky to trace interpretations of traces. So today, pressured by a needy use case, I am rewriting t...

If you look at A Prayer for Owen Meany  through the lens of category theory and functional execution, John Irving didn't just write a novel about destiny—he built a strictly commuting diagram evaluated lazily from a terminal object. Stop here if you do not want to know the end or details of the book! FYI: Info is "fuzzed" below to lessen damage. Most novels, and most human lives, execute like an imperative program. They are Markovian. You start at state A, apply a decision, move to state B, and the future is an open, uncomputed tree. Owen Meany’s life operates under completely different mathematical physics. Here is the categorical breakdown of how Owen’s universe functions: 1. The "eventful location" is a Terminal Object In category theory, a terminal object is an object to which there is exactly one morphism from every other object in the category. The "action" in the "eventful location" is the terminal object of Owen’s existence. Every sin...

How to introduce ML in your company? That is the question that I was asked last Friday. I found myself saying "it is tricky, ML typically comes in a right-angle to the people process, and that does not work!" Right-angle? You might say? And you would be right! Therefore I picked up a deck I wrote last November, kept only the key statements, added the context, and recorded a 17m presentation here: https://www.youtube.com/watch?v=08uEBKft_Bg   which will not tell you "why" but "how", as in "how to introduce machine learning in your company". The finer story here, and not highlighted in the presentation is success with or without machine learning is first about your team maintaining maximum performance throughout the project. See it as a rocket that is maintaining maximum thrust. And for that to happen you must carefully ensure that everyone can invest their maximum with a full understanding of what they and the team wants to achieve. Teams may some...

I was recently approached by an ML company setting up shop in Zurich. To be honest, I’m still not sure if it was a real person, an agent, or just a sophisticated scouting bot. But it sparked the question: What exactly do they see when they look at me? I know I can provide crazy value, but within a certain scope. I also know my digital footprint is sparse. To find out what the world thinks of 'James Litsios,' I went into an anonymous Gemini session and asked a simple question: 'Why would someone hire this man for an ML project?' The answer I got shocked me: a highly accurate "slice" of a man who existed ten years ago.  Let's start with Gemini's response (with some annotations in Blue ).  Then I will update you on how I have evolved my core beliefs from the Gemini expressed basis. Gemini Pro's reply to: Who is James Litsios and why would someone hire him to develop a ML application? Dr. James Litsios is a veteran technologist, architect, and leader b...