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

In classical development, discovery is much an informal process. For example, the Manifesto for Agile Software Development starts with "We are uncovering better ways of developing software by doing it and helping others do it", In high-performance discovery is always a delivery.

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):

• Product
• DSL
• Toolkit of functional programming and serialization concepts presented pre-Elevence (with some Gemini explanations here)

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!

What about teams?

In an earlier post, I state:

1. Servant leaders align communications and expectations to meet their team’s need
2. Sometimes servant leaders lead and their team follows
3. Servant leaders help the team lead itself 
4. Servant leaders encourage emotional energy and enthusiasm
5. Servant leaders foster acceptance of team emotions by individuals and of individual emotions by teams 
6. Servant leaders coach individuals and teams around expectations
7. Servant leaders help team grow and pivot their process to be more productive

High-performance is first about cruising at maximum height, and speed, to avoid turbulences, to stay lean and focused, and deliver the goods. And the most efficient way to do that is to depend on an experienced pilot. In agile terminology, a servant leader. For my projects, a deep tech servant leader.

Applicability

This methodology does not inherently require a team of domain veterans. In fact, on past zero-fail projects (e.g. Elevence), I hired entirely fresh engineering teams. It does, however, depend on the product owner being both a domain expert and a software expert, to the point that they already know what software architecture they need to deliver.

The crux of the method is that it will easily fail with a bad choice of prioritization and order of work. In an earlier blogs I wrote: 

• "the first level of your design ... are directly tied to the most important business concept". 
• "The heart of your software comes first".

Therefore, product needs to enable the architecture by first asking for the critically enabling language features (or if using ML, the critical datasets). A key insight, is that enabling optimality by asking for specific structural properties upfront is not the same as imposing architectural choices! Separation of product and engineering is critical even when working tightly together to deliver high-performance! 

All original content copyright James Litsios, 2026.