Understanding code refactoring — guide for managers.

In the tech world, there is a huge gap in communication between developers and managers. Obviously, there are many cases that it works great, however many times technical and none technical people comes from 2 different worlds, speaking 2 different languages. One of the worst cases is when the developer thinks it is not worth to explain things to the manager, because she or he will not understand the complexity. On the other hand when the manager treats developer like a not responsible child, who don’t understand business or project goals. Personally, I believe the key to good communication is proper attitude and trust. The developer needs to learn how to explain none technical person the complexity of software development challenges. And the manager needs to trust the developer, most of developers are very smart people and when they change the priorities of the tasks in most cases there is a reason for that. As a developer, I found that the easiest way to explain things to the manager is finding allegory from managers world. This article will be an example of that.

Refactoring is an abstract term not only for managers or customers but also for many developers. When people hear “refactoring is needed” it’s like an instant panic attack. I’ve even seen tickets starting with sentence “do not attempt to refactor the code”.

It becomes almost such as mystery as Jedi force is.

Does refactoring is a Jedi force indeed?

The answer is easy, it is not. Almost everything in programming is inspired by the real world and everything can be easily explained. The biggest challenge I found in my commercial experience is to make your listener willing to listen.

Are you still listening? — Let’s start then :)

There are a few reasons to refactor the code. One of them is a trendy nowadays phrase called clean code.

As I’ve mentioned earlier, everything in programming is inspired by the real world, let’s have an example then. Imagine you’re a chief and you just start a new job. Your first task is to cook a healthy meal in 30 minutes for 6 people. Easy as you are experienced chief… however in this kitchen…

Obviously, it’s impossible, you need to clean it first. You can find all you need and make a bit of room to make this dish, customers are waiting now though. However, you do understand you have to refactor this kitchen to make your work possible. Refactoring code is similar, let’s start with cleaning than.

1. Clean code

So what can makes the code dirty? The code is nothing more then loads of files and notes, and if you make notes for yourself you can easily imagine they might be well organized or complete mess. It becomes dirty when it’s hard to read and understand in exactly same way notes or files can be hard to understand. On top of that, the code is doing things, just like your notes on the daily planner, you cannot plan driving exam and to pick up kids from school at the same time for one person. I’ll highlight some of the reasons for code refactoring here.

• When a single file has over 2000 lines of code. Average developer starts to feel confused and lost in code which got over 2000 lines of code. If the developer feels lost how she or he supposed to fix something? It has to be broken into smaller pieces, but not just randomly. It has to follow the development principals, so it is understandable for bigger audience then the author only.
• When code in one file is just messy like notes below. Just like other people, there are well organized and messy developers. It’s more likely to see a messy code in junior developers code it’s just because they do not have enough experience to see that this small part is just a puzzle of the bigger picture. Ability to seeing bigger picture typically comes with the experience.

It was hard to write this code, so it should be hard to read — explained the author

• When code refers to too many other files or when dependencies between files in scheme look like a random spider web. Below you can see the dependencies LLVM project which got over 3000 classes and near a million lines of code. This code could be split into smaller modules which are easier to understand. Just like a drawer with everything thrown in and drawer which has categorized well-organized boxes.

• Whenever dependencies between files are nested — it’s called spaghetti code. When the developer needs to fix simple bug and code is nested it feels like tracking single spaghetti when finally get’s to the bottom, she or he no longer knows where was the start. I have found spaghetti code hardest to refactor and many times I just delete all and start from scratch.

• When there are too many redundant classes and code. It feels like there are too many notes and some of the notes are duplicated, so to order it developer need to trash some of them, reorganize and rewrite others.

• Whenever the code is referring back and forward. This type of code is called a ping pong code, just because whenever the developer tries to understand the code she or he feels like cat below.

• When naming is confusing. Proper code naming is one of the biggest challenges even for senior developers. After tones of tones of bad naming in the code, it might be a huge brain-killer :) Variables, functions, classes and modules need to be organized in the structure which says exactly what it does. Otherwise, in million lines of code, the developer might never find which part is responsible for displaying the red circle if it has been named the blue square.

• When the code has too many nested callbacks. Let me find an allegory for callback then. Imagine you ask your daughter to call you ASAP when she gets to nannies home, otherwise, you will call nanny in 30 minutes from now. So callback is something you need to wait for the result, you cannot make it happen now. Programming is full of callbacks and whenever one callback wait for other callback to happened it turns into something called callback hell. Callback hell is almost impossible to understand and it looks more, less like below.

There is much more of this stinky flowers which can be found in the code, but hopefully, it gives you a better image of what dirty code can be.

The overcomplicated and messy code is likely to be buggy as it’s much harder to predict the use cases and testing scenarios. With the time when dirty code grows it is like with regular dirt, it’s harder to clean it later on. Adding new features to dirty code takes more and more time, so it is good for you to understand how important is to clean it at the beginning and allocate time to keep cleaning during new implementations.

2. Technology

We are leaving in the world where technology keeps changing and the tempo of this changes remind me of Moore law regarding processors.

Every 2 years is doubling installed transistors on silicon chips from the previous years

In programming languages, it changes the same speed or even quicker. For example in the last few years, to solve callback hell on Android platforms developer had to learn about Rxjava1, Rxjava2, Future, Kotlin-Coroutines. So you can easily imagine some part of the code could’ve been refactored up to 4 times during last 3–4 years. Even if it was written properly in the first instance, the code aging itself and with the time it needs to be refactored.

Going back to our kitchen it’s like installing a dishwasher. The kitchen was great, but 15 years ago.

3. TDD

You probably heard from your developer that the code is not TDD. TDD stands for Test Driven Development and it means that the developer writes it’s code to be easy for Unitary Testing. Unit Tests are just other code which tests actual code. In fact theory of TDD says the developer should write Unit Tests before she or he starts writing any other code, the reality is a bit different, however as long as the developer write tests for the code it should be good.

4. Performance

This is the first time none technical person can really understand why to refactor has to be done. It is because the result is measurable and it can be seen in the behavior of the app. Performance refactor result in smoother and quicker running app as well as in lower memory consumption, which means hardware requirements bar is decreased.

So where is the value of refactoring?

There is no value in not refactored code, it makes developers work more difficult many times impossible to continue. Not refactored code made development process extremely expensive. If money is not a value in business then what is?

That’s it, if you like it and you have more confusing terms you feel need explanation please left me a comment.

Thank you!