Posts

Engineering and math, the final frontier, to boldly go where no human has gone before!

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

The Efficient Frontier of High-performance Software Engineering

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"...
Read more

Run Your Engineering Team Like a Hedge Fund

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

High-Performance Software Engineering Explained

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