Programming is definitely not a very easy thing for everyone. There is actually a big difference between developing and programming. I'm not going to go into details of that. Today I wanted to write how much I hate reviewing and making changes to legacy code. It is quite obvious that people working on legacy products will have the same feeling. People who don't upgrade themselves will not usually have any problem. They just go around the same code again and again and get used to it. The real frustration comes when you explore new technologies and understand how easy it is to do things in modern ways.
For the past few months I have been exploring new technologies and frameworks and I even try building applications with the new technology stack. When I do that as a self-learning, I still have to continue working on the legacy code as my company's product is still in old technology. That is when the real problem is. After building a successful requirement in a new app that I build, going back to review the legacy code for a different requirement is really frustrating. Especially when we see easy approaches available but if we are bound to doing things in a complicated manner. For some people who are used to this, it is convincing because they also don't have any other options.
Some of the requirements that we usually get as part of product improvements can be quite challenging to implement using the legacy framework. The source code is huge and it is not really easy to have everything in fingertips. When that is the case, if there is a new requirement, it becomes a bit challenging to first analyze what the requirement is all about and what is already there in the product. Arriving at a solution is the last step but before that, there are lots of hard work involved.
Analyzing the existing code drink our time more than the actual build work. It can even be removal of few lines in the code, but it can take even weeks to understand the impact of the removal and implement the solution. Always for people who work on legacy code, the challenges are more. Fortunately if it is going to a legacy code, we might be able to get some references and documentation online. But still the programmer will have to go through line by line using a debugging tool to understand the code.
When we usually look at the legacy code, it is quite common to find additional bugs as well. Some of the bugs that we identify can usually be something that will need a mandatory fix immediately. This can again drag our time a lot. We would have initially started to work on something but end up fixing something else in the code. It is kind of a deadlock situation where you will not be able to continue your development on the new request without fixing the existing bug in the product.
This can really induce more frustration because it is quite obvious that both are two extremes and it will be easy to work on new programming methods than older ways. And when you have the flexibility to work with few libraries that are available, it even makes our job easier because we may not have the necessity to invent the new wheel all the time. But in situations where you have to work half of the time on a new product and half of the time on legacy code or older technologies, the work can drag lots of time and energy from you.
I'm currently in a mindset where I try to push the legacy work to my team members and show more interest in the new product that I build. My team members also show frustrations at times but I spend some time with them to provide just guidance alone. I have reduced my hands-on work on the legacy products. I think this is the state where people also think about switching to a new role where they can continue to work on new products instead of fixing bugs and doing small enhancements on the older products.
Image Source: Pixabay.com
