Extreme ownership and software engineering

Table of Contents

Extreme ownership
Simplicity
Discipline

“Extreme Ownership” is an incredible book, not only filled with inspirational war stories and leadership principles associated with them. The book also shows readers how to apply these principles to business situations.

According to the authors, Jocko Willink and Leif Babin, leadership is not done by designated people. They claim that leadership is essential at every level in a team or organization. Perhaps some of those principles apply to the daily work of a software engineer.

Extreme ownership

The book’s dominant concept is a difficult one to grasp. What if you were not allowed to blame anyone? Never. Whatever happens, you are responsible. If you make a mistake, it is your fault. If the infrastructure does not work as expected and your software fails, it is still your fault. If someone else makes a mistake, it is your fault. Seriously, it is your fault. If there is a bug in your code, you are the one to blame. Maybe you did not explain what you wanted or did not notice that your colleague was struggling while coding, and the result is subpar.

What else? If you don’t know what to do because the instructions are not clear, guess what? That is your fault. You should have asked for clarification.

You can’t blame your boss when you do boring tasks at work and don’t learn anything. You can’t blame your company when you wake up in the morning, think about going to work, and your nose starts bleeding. You can’t blame your team if they are not motivated because you have failed to clearly outline their duties and your expectations.

The principle of ownership seems so simple. When you don’t like something, you can decide it’s important enough to change, or you can try to ignore it. There is no other option.

There are many occasions during which we put the blame on other people. You may come across a project you need to modify. What if this project has no tests? What if you implement your changes and the existing code breaks? Was it your fault? Well, on the one hand, there were no tests, but on the other hand, the code worked before you touched it! Even if the code was terrible at the beginning, you did not improve the situation, didn’t you?

Would you take the blame? If you read “Working Effectively with Legacy Code” by Michael Feathers, you would know that in such case you should always start with writing tests which cover the existing code.

Extreme ownership comes as extremely difficult. You can’t feel insecure. You can’t be afraid of saying “I don’t know.” As Leif Babin and Jocko Willink say:

When it comes to standards, as a leader, it’s not what you preach, it’s what you tolerate. When setting expectations, no matter what has been said or written, if substandard performance is accepted and no one is held accountable (…) that poor performance becomes the new standard.

Your best results do not matter, what does matter is the quality of your worst work. Is it good enough?

Your team may use the cutting edge technology, organize conferences, and contribute to open source projects. All of that does not matter if at the same time you don’t write tests, don’t come to the meetings on time and don’t make decisions based on indisputable facts and data, but rather make them based on your ego and hype.

Simplicity

Another idea from the book is the principle of simplicity. We, the programmers, have a huge problem with this concept. We are ashamed of simplicity.

People are not going to invite you to a conference if you tell them that your data pipeline is, in fact, just an FTP server and a bash script run by a cron job. You need Kafka. You need Spark. You should read a book about Lambda architecture because there must be an impressive way to copy that 2 GB file from one place to another.

The problem of the complication of the simple is not only related to the technology we use but also to the features we implement. How often you implement a redundant feature just because it will look cool during the demo and you can proudly add it to your CV?

Even our goals are not simple. Look at the user stories. How many of them look like that: “As an X I want Y.” We shortened the notation, but we lost the meaning. You can put anything you want in such user stories, and it will always make sense!

What is missing here? What is the goal of this user story? How are you going to measure the outcome? How can you take responsibility if you don’t know what you are trying to achieve?

We took shortcuts and left out the real reason behind the user story. We focused only on the feature, not on the value we deliver to the users.

Can we try a different approach? In the book “Lean change management” Jason Little suggested running experiments, such experiments have hypothesis which can be based on the following template:

We hypothesize by <implementing this change> we will <solve this problem> which will have <these benefits> as measured by <this measurement>.

You can argue that Jason’s template of user stories is not simple. Sure, but the decision-making process is simplified. What matters the most when you make a decision? It is all about setting priorities. Now you know which of your priorities are going to be affected by the features you implement.

Simplification lets you focus on the decisions that matter. With this idea in mind, you are also not going to make a decision which is difficult to change.

Do you remember the principles of clean architecture? You are supposed to defer most decisions. It is always better to make the final decision later when you have more information. It is also possible that at some point you will no longer need to make the decision.

Discipline

Another important concept from Willink’s book is the idea of discipline. This principle is about minimalizing the number of decisions. If you know what you should do and how to do it, you are not going to spend time thinking about your actions. If your team follows a clearly communicated set of rules, you don’t need to explain your choices.

In software development, we often say that TDD is a discipline. Does it mean that you can choose when to write tests? I don’t think so. If it really is a discipline, you are not allowed to write any production code if you don’t write a test too.

I know that Dan North says you don’t need to write tests if the code you write is an experiment. He also says that every new feature should start as an experiment because you don’t know yet if it is going to be useful and how to write it properly.

Sure, just remember that he also says that such approach is an advanced technique. It requires, guess what? Discipline. At some point, you must either remove the code or write the tests and refactor it. You are not allowed to let the untested code stay in your software longer than it is necessary to decide whether you need it or not.

Whatever approach you choose there always are strict rules you must follow. You are also responsible for telling your boss, the product owner, the stakeholders, etc. that your team needs some time to test the code and ensure quality.

You can’t just focus on delivering new features. You need more time for implementation which means you also have more time to think about the features. After some time, you may realize that some of the features are redundant. You may also notice that implementing them costs you more money than you are going to earn.

In the last chapter of Extreme Ownership, Jocko Willink and Leif Babin offer us one more important piece of advice:

Nothing is easy. The temptation to take the easy road is always there. It is as easy as staying in bed in the morning and sleeping in. But discipline is paramount to ultimate success and victory for any leader and any team.

Someone, maybe you, may decide to take ownership and simplify the scope of your project. You may decide to take ownership and impose discipline on your team. It will make a big difference even if you are not the team leader.

Your users will be grateful for that. Look at the most successful applications. They are simple. They do one thing but do it well. Such results are not possible when everyone is doing whatever they want.

Extreme ownership and software engineering

Extreme ownership

Simplicity

Discipline

Perpetually dysfunctional software

The beauty of properly used statically typed languages

Extreme ownership and software engineering

Extreme ownership

Simplicity

Discipline

Perpetually dysfunctional software

The beauty of properly used statically typed languages

Related Posts

Theory of constraints in data engineering

Turning greenfield projects into brownfields projects

User story mapping for developers