Third-Order Software

All software development (and most creative endeavors) go through three phases with three separate goals. I call this Third-Order Software, something like the Kardashev scale of software planning.

1. Prototype / Minimum Viable Product
   Build something that helps explore the problem and allows for iteration.
   You now have the right solution for solving the wrong problem.

2. Revise and Refine
   Identify the correct problem through iteration. Iterate on the solution until you have solved the correct problem.
   You now have the right solution for the right problem, but it was not designed to do this well.

3. Rebuild and Replace
   Now that you understand both the problem and the solution, start over and build it efficiently.
   You now have the right solution for the right problem, built in the right way.

Plan to throw one away; you will, anyhow

The First Order - Try

1. Describe the problem as best you can

2. Build something to solve the problem

3. Measure the result

4. Learn that the problem you actually had was a different problem

5. Describe the problem better than before

It is foolish to answer a question you do not understand. It is sad to work for an end that you do not desire.

Software, especially, goes through this set of problems. Whole industries exist to try to nip this problem in the bud, but it's rare that it actually works or that the outcomes match the expectations.

I was once tasked with improving a translation system, and I had no familiarity with internationalization. Translation often feels like a simple problem and something that can be easily rebuilt in an afternoon. As I began to dig into the needs that we had, I was able to prototype a simple implementation, but it immediately began showing edges where we wanted additional features. I was thankful that I hadn't build a large framework when I didn't even understand what to build.

This concept of prototyping was extremely valuable in a product space that I had never worked in before. The ticket I was given was straightforward and simple, but it did not provide what correct would look like or what good would look like. Building a very cheap implementation allowed me to explore that space and get feedback from people who also did not know how to ask for what they wanted.

The goal of trying is to understand the problem, not to solve it.

We shall find the answer when we examine the problem, the problem is never apart from the answer. The problem IS the answer, understanding the problem dissolves the problem.

The Second Order - Fix

1. Do research to figure out the right problem

2. Make a change

3. Measure the result

4. Ensure you've actually solved the problem, otherwise, goto 1

Almost all product definitions are based upon incomplete data and never use actual user data as the source of truth. It's very difficult to get real user data about something you haven't built yet.

When I was working at Square, my team was given the task of updating the know your user system. This was a compliance requirement and most of onboarding, making it one of the first touchpoints for all users who took payments at Square. the system that we were handed was supposedly mature, but we were noticing that users were dropping off or facing onerous requirements and complex workflows. We had new features to build that didn't fit the framework. We were stuck.

The most serious mistakes are not being made as a result of wrong answers. The true dangerous thing is asking the wrong question.

We focused in on user research and metrics gathering so that we could better understand our current state. Understanding just what we had inherited helped us guess around what needed to be done to improve. We did an analysis of the codebase and understood the assumptions made in the architecture. We compared it to current best practices both in our codebase and the industry, based upon our experience.

The combination of metrics, user research, and investigation allowed us to come up with a recommendation for improvements that would then re-inform our metrics and user research, allowing us to move closer to what we considered the right outcome. We had to become experts, and that was the first and most important step.

An expert is someone who knows some of the worst mistakes that can be made in his subject, and how to avoid them.

The Third Order - Rebuild

Now that you:

1. Understand the problem

2. Understand the solution

3. Have familiarity with architecture

4. Know what was hard

5. Know what you liked about the implementation

6. Know what you wished you had done

You can rebuild with a lot more confidence than when you started. Rebuilding shouldn't feel expensive. This process is a cheap iteration, not a full rebuild. If you don't spend significant time building the original version of something, it won't feel like you are throwing away a huge amount of value based upon learning from it. The lack of investment is a feature, not a miss.

I spent 3 years working on a budgeting system that allowed me to solve the exact problem I had. It matched my personal desires and my way of thinking about money. When I tried to sell it, I found a very difficult truth — finding people like me is very difficult work, and they might not even want to pay for software that does what mine does.

We sunset the business, divested our funds, and retired the software. This was difficult, but led to a recent opportunity thanks to agentic development.

The three years I spent refining the product gave me incredible insight into the nuance, pitfalls, and architecture of the product I want. I'm able to describe every nook and cranny of the problem, AND I know the difference between what I want and what I don't want in such fine detail that I was able to rebuild the system in less than 3 partial days.

If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.

By doing less, we are able to focus more. The purpose of the first version of software is not to build a product or solve a user's needs, it's to gather as much information as possible and learn as quickly as possible what is actually valuable. When you have learned what you can, you throw away your notes and build the right thing.

Some things to think about: Refactoring is cheap, now. The cost of building third-order software has become so much cheaper, and there is so much AI help in evaluating the current state, probable needs, and architecture of a codebase that it's almost silly not to rebuild after you've learned something.

If you seek tranquillity, do fewer things, better... Because most of what we say and do is not essential, if you can eliminate it, you'll have more time and more tranquillity.