The secret of working with legacy code on a software team

Have you joined a new team? Does the code look so terrible you start to question your career decisions? Do you look at other team members and wonder what’s wrong with them? Does everything look like ancient legacy code? Even the stuff written a week ago?

Table of Contents

Why do other people make terrible decisions?
Always assume that people are doing their best
Can I guess what they were thinking?
Always assume the best effort

Let me tell you a secret that will forever improve your ability to work with awful legacy code.

Why do other people make terrible decisions?

Did you ever wonder how people make terrible decisions? Not only in code but in life. How does it happen?

Why do people take drugs and overuse alcohol if everyone knows it will destroy their lives? How do people decide to drive a car in an urban area at speeds exceeding the speed limit three times? What does it take to choose you should sit all day and watch TV while you know that sitting will eventually kill you?

Are they stupid?

I will shock many of you, but nobody makes a stupid decision. Nobody.

I know it’s hard to believe when you look at other people. But bear with me. Let me explain my idea.

No person wakes up and decides, “I will make something stupid today, and I know I will regret it for the rest of my life.”

Every person on the planet makes the most optimal decisions possible. Of course, “optimal” is subjective. Sometimes, the most “optimal” means choosing actions that take the least effort. Many optimize for short-term pleasure. Others optimize for avoiding awkward social situations.

Those decisions may be irrational from our point of view, but nobody makes anything stupid. At least, they think they are rational. If we uploaded their beliefs, knowledge, and assumptions into your brain, you would make the same decision.

Of course, we are talking about making decisions while being calm. Enraged or panicking people are hardly rational. But they make optimal decisions too. Although, if all you care about is survival, you will most likely, regret the decision later.

Always assume that people are doing their best

Programmers who worked on the team before you were doing their best. Always.

Those programmers had some assumptions about the reality and beliefs about the project’s future. They had some knowledge about programming and the business domain. Using all of that, they made the best decision they could make.

Maybe you know more than they knew. Perhaps some of their assumptions were wrong. Now, you could make better choices. Or you are disillusioned. What if your assumptions are incorrect? How can we know it? We can’t.

If everyone does their best, we cannot judge whether we are right or wrong because such judgment requires more information than we already have.

Perhaps, next year a new person will join your team. They will look at the code you have written and be disgusted by it. They will move all of your code to the “old” directory and start coding from scratch. And they may be wrong too. But they do their best, just like you.

Can I guess what they were thinking?

Imagine this. The next time you need to choose an action to take, don’t keep your knowledge, assumptions, and goals in your head. Write them down. If you work on a team, ask everyone to write down their assumptions and objectives.

What’s the reason to do it? When you force yourself to create a document, it’s harder to overlook details. Once everybody reveals their knowledge, making a decision as a team is easier. But… that’s not entirely true.

You didn’t reveal everything, did you? What did you skip on purpose?

What are you hiding? Is there anything you cannot show to your coworkers? Any opinions that aren’t socially acceptable? What if you choose technology because you want to learn something you need to get a better job? Would you reveal that in the document? Probably no, but it still affects your decision.

Some assumptions and hidden motives always stay in the head. Even when you write it only for yourself, you may think, “What if someone sees this document?” “What if it leaks out of my computer/cloud account?” It’s true in your case and true for everyone else.

How would you take that into account when you review other people’s decisions? What about their hidden agendas?

You can’t guess what they were thinking.

If you think you can, you are wrong. Your idea of other people’s thoughts is only one of your assumptions. It’s affected by your point of view and your experience. Stop guessing. You aren’t in their heads.

You can’t know what they thought even if they wrote everything down. There were some things they skipped. Maybe they wanted to hide them. Perhaps they thought those details weren’t necessary. The reason doesn’t matter. The point is, we don’t know their “input data.”

Always assume the best effort

From now on, you should always assume the best effort and good intentions when you judge other programmers’ choices.

You don’t have to agree with people. It doesn’t mean you should accept their point of view. All you need is an assumption that everybody makes the best possible decision.

You can’t be angry at people who were doing their best. You can’t laugh at them or complain about their choices. All you can do is make the best of what you have.

The secret of working with legacy code on a software team

Why do other people make terrible decisions?

Always assume that people are doing their best

Can I guess what they were thinking?

Always assume the best effort

Functional programming in Python

A comprehensive guide to Kappa Architecture

The secret of working with legacy code on a software team

Why do other people make terrible decisions?

Always assume that people are doing their best

Can I guess what they were thinking?

Always assume the best effort

Functional programming in Python

A comprehensive guide to Kappa Architecture

Related Posts

Don't use AI to generate tests for your code or how to do test-driven development with AI

Using Abstraction Layers to Tackle Common Problems with Legacy Code

Why should you practice TDD?