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 fail to achieve previously promised goals
  • Never fail deadline because of waiting on others
  • Never fail to use all your team members
  • Never fail to stay productive because of exhaustion
  • Never fail because of misalignments
  • Never fail 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 mentioning teamwork, although note teams are mentioned above as "Never fail to use all your team members".
I do not consider: "We are uncovering better ways of developing software by doing it and helping others do it", from the Manifesto for Agile Software Development. Because I cannot afford it!

Extreme Programming, Lean Startup (my analysis of the method), are examples of development methodologies that took agile and made efforts to improve productivity.  Lean Startup is interesting here because it formulates drive as a process cycle over: 
  • Build
  • Measure
  • Learn

Notice how measure implicitly accepts that failures happen! Ouch!
I have been CTO and/or head of development for over twenty years. My principal learning is: you cannot afford to fail! I typically explain this to my teams as: As a startup engineering team, failures will kill you. My way to visualize things is: "I imagine I have a six shooter (revolver), that gives six shots I can use to fix things when I fail, but no more"!


Technology is the enabler to productivity with low failure rates! 

High-Performance Software Engineering

I call my "no fail" approach "High-Performance Software Engineering". Sometimes I have described the approach as "run your development like a hedge fund". As inherently the approach is to use technology and math to deliver what you want, as fast and cheaply as possible.  I highlight the core of the concept below. And to note that while above my agile description skips 10+ supporting efforts, here we are skipping more than twice that amount of supporting efforts. So for example I skip that you need to need to take a highly model driven approach, to the point that not only do you model your product domain, you also model your software implementation domain. Therefor I take a "show and tell" approach below.

My current process cycle drives over:
  • Product
  • DSL
  • Algebraic and formal methods
In the past, for Elevence Digital Finance's digital ledger and smart contract of rights and obligations (where I was CTO and product owner):
And more recently, for signal processing machine learning:
  • Product
  • Labelled data
  • ML model
The idea is the following: the product/business person can approach their work any way they want, therefor in the process cycle above, they are just "Product" with no extra constraints. The important aspect is that instead of product describing what they want, they specify it. For example above, a product owner might write an expected concept within a DSL. Or they may produce labelled datasets that present what is desired, or not, for a machine learning effort. Specifying a requirement, or writing a story is optional, as the DSL or labelled data contain everything the engineering team needs to know. If the DSL or machine learning capability is not good enough for their product specification, they still write DSL, they still label data. Engineering's task is to make that DSL, or an equivalent DSL, or machine learning capabilities "real".

Towards a broader adoption of High-Performance Software Engineering?

Agent-Driven Development (ADD) is the above with the following process cycle:
  • Product
  • Agent Guidance
  • Agent Farm
Agent guidance currently lacks rigor, but progress comes quickly!

All original content copyright James Litsios, 2026.