Principles of improvement

No one plans to fail, yet everyone has seen failed projects. Why is that? I don't know.

At least one of the reasons for failed projects is the over-reliance on good intentions and hope that it'll just work out. We're going to make things good because we want to make good things so they're going to be good. Somehow, that isn't enough. A project can still fail and when that happens and it's our work then we justify it with external factors. Yet, when it's someone else's project the same arguments sound like excuses. After the fact it's easy to point out the obvious or the logical changes that should have been made.

Do I have a solution for that? Not entirely. However, over the years, I have developed and adopted some principles that I believe help me in making things better.

Principles

These principles are not new, they're not mine, and they're not unique. They're just a collection of principles that I find useful and that I try to follow. The common theme is that mistakes happen, and almost all of them are of human nature. It's ok to make mistakes, but it's better to minimise their occurrences and learn from those that have already happened.

Reversible over irreversible changes

Try to position yourself in a situation where you can make an (easily) reversible change. That's in contrast to irreversible change. The principle is also sometimes called "two-way door" vs "one-way door". That's to highlight that almost every change can be reversed but with two-way doors to reverse it by going back through the same door, whereas with a one-way door you need to rely on another set of doors to get back. In this case, reversibility means that there's little to no cost to revert the change. With one-way doors, the cost, or the likelihood of high cost, is much higher.

Processes over good intentions

A process, especially one that is written down, is easier to follow than some ideal scenario in one's head. Good intentions, especially those that aren't written down, can be too optimistic and too vague. A "good intention" depends on someone's skill set, specifically adaptability, which has its limits. A written-down process can be followed by anyone, provide feedback on, and improve.

Automation over manual work

If a task can be automatically input or validated, then it should be. Manual work is error-prone and time-consuming. Automation can be tested and improved. Doing things manually also relies on our memory; that in the future we'll also know how to do it. With automation we document compressed knowledge - what and how - rather than all intermediate steps.

Documentation over tribal knowledge

If you learn something, write it down. There are jokes about job security through tribal knowledge, but this is extremely short-sighted. It's more productive for everyone when multiple people can read about something at the same time rather than a single person explaining the same thing multiple times. From hiring and leading, having someone as a bottleneck means that I'm going to think about how to remove the bottleneck. In contrast, if everyone learns from your experience AND you can contribute to the team, you're the most valuable person.

Simplicity over complexity

You might impress new people by showing how much you know on a specific topic. However, to impress somehow who has worked in the domain for a long time, show how you took a complex topic and made it simple. Simplicity often means fewer moving parts, which translates to a smaller breaking surface. In complex systems, it's also easier to make a mistake and harder to find it.

Something over nothing

The world evolves, and so do problems. If it takes months or years to come up with a solution to a current problem, chances are that when you're done, the problem is different. Often, one doesn't even understand what the problem is in the first place as they don't have all the information. Getting something out there, even if it's not perfect, means that we can observe whether the problem is as we know it or whether it changes.

Unity over exceptions

Also known as "don't reinvent the wheel." If there's a tool that helps solve a specific problem, start with that. If your company has a popular tool for a specific problem, then don't start by introducing a new one unless you have a very good reason. This is because you're definitely going to have some problems with the tool, but your goal is to solve the problem, not to verify if the tool works. The existing tool has likely already been tested, and there are others who might help you in case you stumble.