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...