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

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

First try (from Gemini 2.5 Flash) Software architecture defines the system's fundamental structure , outlining its major components, their high-level relationships, and the overarching principles and quality attributes (like scalability or security) that guide its construction. It's the "what" and "why" of the system's foundational choices, which are costly to change. In contrast, software design focuses on the detailed internal workings of individual components and modules, specifying their logic, data structures, and algorithms to implement the architectural vision effectively. It's the "how" of putting those foundational pieces together, generally with a lower cost of modification. Second try (with my input) Software architecture defines the system's fundamental structure , outlining its major components, their high-level relationships, and the overarching principles and quality attributes (like scalability or security) that ...

I have been writing higher-order functional programming in Python for the last few weekends: hofppy ( https://github.com/equational/hofppy ) will be a Python library. For the moment it is a collection of Jupyter notebooks. My initial goal was to have a handy FP toolkit which supports applied math with JAX's JIT. Yet I realise that in fact what I am really doing is reimplementing the generic part of a compiler for a reactive (trading) language I wrote in 2010 in F#, while including a few tricks I picked up since then, the primary one being to think of code as implementing a synchronous execution model. There is really very little code like this on the web, therefore why I am doing this open source. This blog is in part written to mention the above, as already the first JAX JIT supporting monad and comonad models are "nice". Yet this blog is also to bring up the subject of the process of creating new technology. My recipe to do something new, such as lead a team on a new su...

Here is a handy way categorize levels of software sophistication: Software implements features Software  supports software that implements features Software supports software to support software that implements features Here is handy way to categorize levels of people skills: Person implements features Person supports people that implement features Person support people that support people that implement features Let us combine some of these people skills and levels of software sophistication: Person implements software that implements features Person implements software that supports software that implements features Person supports people that implement software that implement features Person implements software that support people that implement software that implement features Person support people that support people that implement software that implement features ... Note how entry 4 is a hybrid of people skills and software expertise! The above lists actually makes sense, ye...

A classical way to look at parallel / distributed systems is in terms of: Work-Efficiency Parallelism Locality  This is one of those inconsistent triads  (or trilemma ), where only two among three properties can be chosen. For example, a system can have both work-efficiency and parallelism, or parallelism and locality but cannot be fully work-efficient, parallel and local. This is not the only inconsistent triads to think about when designing scalable systems. Here are more: Velocity Resources Work Momentum Quality Traffic And of course the CAP theorem's: Consistency Availability Partition tolerance And the important: Fast Good Cheap All of these are ultimately important, yet some of these are more practically useful. Especially when you realise that you can weaken the inconsistent of these triads by introducing additional complementary properties.  To illustrate this with examples: Two people must work together vs an engineer and a sales person must work together Two tim...

Failing smart   My agile mantra is much: "Failures must bring you closer to your vision" It is a mantra I have often used. And very much how I approach agile innovation (e.g. see Search and Vision for Systematic Innovation ) However... It is only partially true, as failure may happen simply because you are disorganised, with no relations to your vision. Fixing organisation issues helps avoid drifting further away from your vision, it does not bring you closer to your vision! Still, unmanaged organisational issues will eventually consume you 'from within', therefore they too must be addressed. Can we focus on fixing organisation issues? Can we identify a subset of failures as 'organisational failures', and others as 'non-organisational failures on the way to our vision'? The simple answer is yes! Yet we must know what we are looking for. Six types of failures When I act as agile manager I try to distinguish between six types of failures. These are: F...