Advice to programmers: If it works, don't fix it. Or?

Imagine software that you work on. It was written by programmers before you joined the team and the software works properly. There are some bugs that need to be fixed but it does what it’s supposed to do. Nothing else. This is what others see from outside of the code. Software that solves customers’ problems and works as expected.

But what about the code? What about the programmers? What do they think about their software?

As one of the programmers that built this software, you see totally different things from inside the code. First thing first, you think the code base is so big. You know certainly that this software could have been written with much less code lines by providing the same functionality at the same time. The codebase seems so complex to you. You know that the code could have been written in a better, simpler and well-structured way. Adding new features or implementing something new is hard and painful because you have to consider the other parts that are connected to each other. The modules are not loosely coupled. Therefore making changes take too much time. What about debugging? Finding bugs and fixing them takes too much time as well.

Besides the bad design and ugly code, the software works properly and the customers are happy. Now you are at the crossroads. There are two possible ways for you. The one way tells you that you should follow the old engineering adage “if it works, don’t fix it” and another one that tells you that you should do some refactoring to make your job easier while working on your codebase and have more readable and understandable code. Which way would you prefer? Would you follow the old engineering adage “If it works, don’t fix it.”?

Two different programmer mindset

The answer to that question can be simple but before explaining the appropriate answer to that question, I want to introduce you two different programmer’s mindsets when it comes to fixing bad code that works properly.

One type of programmer’s mindset believes in the old engineering adage: “If it works, don’t fix it.” To them, their code style doesn’t matter. They are result-driven programmers. It can be a complex, bad structured code, opposite of the important programming principles but they don’t care about how well the code is written. They just care about what it does. So to these programmers, fixing badly written code is a waste of time. It just works. Why should they touch it?! And besides, there is a big risk of introducing new bugs while fixing the bad code. So what will they do? They will not touch the code and continue following the old engineering adage.

On the other side, another programmer’s mindset that sees the code as the artwork will be uncomfortable with that kind of situation. They will feel disgusted while reading badly written code. They will try to fix each piece of code in the project because they care about the code style a lot and every code in their project should be written as an artwork. They are too obsessive about their code style. Even if other programmers write well-structured code, they will try to change that code part to make it suitable to their own style. So basically they don’t follow the old “if it works, don’t fix it” adage. They will fix everything by their own mindset. In the end, it doesn’t matter to them if it works or not.

What would be the best solution that works for you?

Find the code parts that you work actively on the most and fix these parts to make them more understandable and readable. Don’t touch other parts if they work as expected and they are bug-free. Why is the core that much important? The core parts of your software are the parts you will work on the most. You will read these parts more often. You will make changes in those parts more often than the rest. If there is a need for adding additional functionalities or implementing new features, they will be connected directly to the core. Most of the bugs will be introduced from the core part which means you will spend most of your time debugging core parts to find and fix the bugs. Remember the 80/20 rule (Pareto Principle), “20 percent of the code has 80 percent of the errors. Find them, fix them!”

What about the other parts?

Those parts are the ones that you will rarely work on. They are bug-free. They were written maybe even months or years ago and they work as expected. They are just written in an ugly way, even though they could have been written in a simpler, more readable and understandable way. This doesn’t mean that you have to fix them too. God knows when you will have to read them or change them again. So these parts can stay as they are. Forget about them. No need to fix them. You can spend your time working on the more important stuff.

Why is fixing core parts so important even if they work as expected?

If you want to serve your customers for long years, you should have a maintainable product. A maintainable product means that making changes is not a struggle. Debugging and fixing bugs shouldn’t take too much time and adding new features is also easy. So as a result, your programmers are happy and your customers are happy too.

As Martin Fowler said in his Refactoring book:

“When you think about programmers, most of us will think that they spend most of their time writing code. Actually, this is quite a small fraction. Programmers spend most of their time reading the code and debugging it. Every programmer can tell a story of a bug that took a whole day (or more) to find. Fixing the bug is usually pretty quick, but finding it is a nightmare.”

The more well-written code you have, the easier you understand the code. The more understandable code you have, the easier your job is.

That is the reason why not following the old engineering adage (if it works, don’t fix it) for the core parts of your software is an important decision you can make.