Four essential laws of programming

There are two distinct kinds of software:

• Software as a tool is designed to make a given task faster, simpler, safer, cheaper, or more reliable.
• Software as a financial asset is designed grow the wealth of its investors.

Much as it seems like these goals should be aligned, all real-world evidence points to them being incompatible. The second type of software tends to be worse by every measure of the first (if it exists as a usable product at all) and tends to get steadily worse over time. It’s also the dominant type of software product in the world today. In fact, software as a tool is so rare and fleeting that when you find it, it tends to be either painfully obscure or alone in its product category, and the conversation around it is punctuated by fear: is it really what it claims to be? Is it hiding something? How long can it last before it’s devoured or destroyed by one of its software-as-asset competitors?

My sole professional interest is in software as a tool. This is a choice I’ve made: I care about building applications that work well and are enjoyable to use. That’s what I’ve spent my career learning to do. I’m a programmer, not a hedge fund manager. So this post is about making good software, completely putting aside financial valuations.

For anyone who shares my interest, I’ll briefly share what I’ve come to believe are the essential laws of good software.

1. In math, “velocity” includes both speed and direction. In software, direction is so important as to trivialize speed.
2. Code is primarily documentation, not function.
3. The level of care exercised by the programmer is a load-bearing intangible.
4. The primary asset produced by a software team is not the software, but the team.

1. In math, “velocity” includes both speed and direction. In software, direction is so important as to trivialize speed.

Many software teams measure velocity, defined as the amount of work completed per period of time. But that’s really only a measurement of speed, which isn’t nearly as important as direction.

At its best, programming is slow, methodical work, with frequent adjustments based on feedback from real users. It’s always been possible to produce garbage quickly, but it’s a dead end. If the destination is garbage, it doesn’t matter how fast you get there. Building something useful, however slowly, is where literally all the value lies.

2. Code is primarily documentation, not function.

Code is a form of documentation, above and beyond its role as machine instructions. This isn’t a new idea:

Programs must be written for people to read, and only incidentally for machines to execute.

Structure and Interpration of Computer Programs, MIT Press, 1984

Good software can only be crafted by programmers who understand it and put significant effort into making sure other programmers can understand it, too. There’s no other way. This was an absolute requirement in 1984 and it’s no less absolute in 2026. It’s universally true, and I swear it’s true, and every piece of code I’ve interacted with in my career has given further evidence that it’s true.

3. The level of care exercised by the programmer is a load-bearing intangible.

It’s impossible for a non-programmer to know if an application is well-written, and no automated system or tool can provide much assurance either. The person or team who wrote it has to care. If they’re not committed to building something that lasts, their code will tend toward the path of least resistance and lowest quality.

4. The primary asset produced by a software team is not the software, but the team.

When a technically competent team has worked together for a long time on the same product, their expertise is invaluable. They can answer questions about it from memory, build new features quickly and safely, and guide its development with a strong understanding of the user, the business, and the domain. They are, in a very real way, more valuable than the application itself. If the application breaks, they can fix it; if it becomes obsolete, they can update or rebuild it. The application can’t do the same for them. It’s easy to mistake the golden egg for the goose, but an application is simply a manifestation of a team’s expertise over time.