This article is part of a series about complexity metrics:

“This part of the codebase doesn’t feel right!”

This was Dave, your colleague developer, arguing in another never-ending meeting to rewrite a part of your company’s codebase. His arguments? Technical debt, high entropy, and the fear of the legacy system.

Our work, as developers, pushes us to take many decisions, from the architectural design to the code implementation. How do we make these decisions? Most of the time, we follow what “feel right”, that is, we rely on our intuition. It comes from our experience, an important source of information. But the same intuition can the source of many problems too. We’re humans, and we are subjects to many biases leading to wrong assumptions.

Have you ever wonder what was The Beginning of All Things™?

In other words: have you ever wonder what Vim is doing when you start it? What files are sourced, why, and in what order? If you don’t really care, I encourage you to reconsider your position. Knowing what Vim is doing at startup lets you speed it up, overwrites some defaults from the plugins you’ve installed, or even creates your own filetypes. In short, it gives you even more power to customize Vim to your precise needs.

When I first heard about the SOLID principles as a young and innocent developer, many of them seemed confusing to me. The Open-Closed Principle looked easy, however: we should extend the behavior of our classes instead of modifying them.

I did extend the behavior of my classes indeed! Mainly by using inheritance in one form or another. The end result? An abstracted mess, where everybody was wondering what was the use cases my code was covering, hidden under a cheer amount of abstractions and indirection.

This is the sixth part of this series to learn Vim from the ground up:

You’re now in your garden, sitting down in your favorite chair, contemplating a fabulous table full of the tastiest food. While delighted by your fantastic breakfast, a fresh breeze refresh your warm skin in this hot summer day. You hear the little birds singing in unison. The vivid smell of the young grass and the delicate and subtle aroma of your tea fill your nostrils. Everything is in perfect harmony; all your annoyances, problems, or negative thoughts are far away from this pure state of bliss.

“We need to stop everything!” shout out Dave, your colleague developer, during a meeting with the stakeholders of BigBuckEcommerce, the company you work for. “Our application is a legacy system. We need to rewrite the whole thing before it’s too late! It will explode! We can’t manage this beast any longer!”

If I had received a coin each time the term “legacy” was thrown in a discussion about software development, I would write this article from a private island in my personal mansion. We all use these words as if they were widely known and accepted concepts, using them as arguments to take action.