{"id":26641,"date":"2020-08-26T12:06:31","date_gmt":"2020-08-26T11:06:31","guid":{"rendered":"https:\/\/dev.wisdomignite.pt\/itv2\/?p=26641"},"modified":"2022-05-26T16:12:26","modified_gmt":"2022-05-26T15:12:26","slug":"you-will-never-get-rid-of-legacy-code","status":"publish","type":"post","link":"https:\/\/dev.wisdomignite.pt\/itv2\/2020\/08\/26\/you-will-never-get-rid-of-legacy-code\/","title":{"rendered":"You Will Never Get Rid of Legacy Code"},"content":{"rendered":"\n

Most of us have been there. Your company wants to re-do some of its components using the latest technology<\/a><\/strong>\/architecture\/patterns\/rules\/you name it. They say: \u201cWe need to kill legacy.\u201d<\/p>\n\n\n\n

\"You<\/figure>\n\n\n\n

But what is this, really?<\/h2>\n\n\n\n

According to Wikipedia<\/a>, legacy code is:<\/p>\n\n\n\n

\u201cCode inserted into modern software for the purpose of maintaining an older or previously supported feature<\/em>.\u201d<\/p><\/blockquote>\n\n\n\n

In other words, code developed in different circumstances, to support an old feature that is part of your product.<\/p>\n\n\n\n

In reality, the most common cause for this to happen is when reality changes. Software is developed, taking into account several requirements for each feature. These requirements are essentially from two types: functional and non-functional. The first type tightly connects to the business you are in. It reflects what your product is supposed to do, describing business rules and restrictions. The second type links to restrictions that are related to the environment of your business. It refers to problems such as availability, security<\/a><\/strong>, performance, and reliability.<\/p>\n\n\n\n

When looking at these two types of requirements, it\u2019s easy to see which one is more subject to change. As your business changes, your product also must change. Usually, this leads to changes in code that you initially didn\u2019t think of, and causes it to have a more flawed design than you wished.<\/p>\n\n\n\n

Legacy code creation is directly proportional to the number of change requests that you get<\/em><\/p><\/blockquote>\n\n\n\n

This relation brings a question: \u201cIf that\u2019s true, how do you kill legacy when you\u2019re in a highly volatile business?\u201d<\/p>\n\n\n\n

Quick answer: you don\u2019t.<\/strong> \ud83d\ude42<\/h4>\n\n\n\n

In this case, it is common for the business to change more often than you develop your product, which leads to having new features that are born legacy.<\/p>\n\n\n\n

If your product serves a highly volatile business, you don\u2019t kill legacy. You manage it<\/p><\/blockquote>\n\n\n\n

Managing legacy<\/h2>\n\n\n\n

A legacy-free product is a product that serves no purpose. We all need to remember that software only exists to support specific business needs and that those needs will change. Frequently. That\u2019s why the only software that can be legacy-free is the one that serves no business.<\/p>\n\n\n\n

As much as you try, you will always have your fair share of legacy code. And that\u2019s a good thing! It means that it is useful enough for someone to need a change.<\/p>\n\n\n\n

Isolate your legacy code<\/h3>\n\n\n\n

Legacy code is typically code that was already tested in the most challenging environment of all: production<\/a><\/strong>. It usually means that those features are stable and solve the problem, as described in the first requirements.<\/p>\n\n\n\n

Avoid keeping maintenance on that code. If new requirements arrive, only then consider the migration to a new service.<\/p>\n\n\n\n

Understand the value of those features<\/h3>\n\n\n\n

And I mean money-wise. Not personal or emotional value. If it is a significant part of your income, it may be worth the time to rethink how it should be implemented. But it\u2019s common for the legacy features to have more costs than benefits. These costs increase even more when you take into account the maintenance costs. In this case, the best you can do is to set a date for that given feature to be deprecated. After that date, delete the code that is no longer used. Otherwise, it will cause entropy. And if you need it, you still have it in version control.<\/p>\n\n\n\n

\"You<\/a><\/figure>\n\n\n\n

Legacy Code vs. Technical Debt<\/h2>\n\n\n\n

These two concepts are often mistakenly used. It is common to hear someone saying: \u201cI hate to work in the application X because it is legacy.\u201d This accusation is hardly true. A legacy product doesn\u2019t necessarily have a poorly written code. One thing is an application that supports an old feature, designed for another reality. Another is an application that has lousy code, hard to read, and with dependencies all over the place. <\/p>\n\n\n\n

But why are those concepts so often connected?<\/h3>\n\n\n\n

Since 2008 we\u2019ve seen a boom of startups rising from nowhere. Everyone went wild, implementing their ideas, and trying to put them to the market. \u201cThe early bird gets the worm\u201d is an old proverb.<\/p>\n\n\n\n

Most companies were competing with time itself and needed to put their product live as soon as possible.<\/p>\n\n\n\n

Rush is the enemy of perfection<\/em><\/p><\/blockquote>\n\n\n\n

\"You<\/a><\/figure>\n\n\n\n

The business needs require any startup to have their products shipped before there was any time to think or evaluate possible alternatives to the fastest solution. It led to most MVPs to be shipped without much attention to code quality, especially when it comes to readability and scalability. There were other priorities in the game. That\u2019s why most legacy products (which are common to be the company\u2019s MVPs) are full of technical debt.<\/p>\n\n\n\n

But slowness is enemy of objective<\/em><\/p><\/blockquote>\n\n\n\n

However, this is needed for a company to survive. As I mentioned before, any software is just a tool that supports a business. We should never forget that. If these startups didn\u2019t place their products in the market as fast as they did, they would probably not be here anymore.<\/p>\n\n\n\n

Respect your legacy!<\/h2>\n","protected":false},"excerpt":{"rendered":"

Most of us have been there. Your company wants to re-do some of its components using the latest technology\/architecture\/patterns\/rules\/you name it. They say: \u201cWe need to kill legacy.\u201d But what is this, really? According to Wikipedia, legacy code is: \u201cCode inserted into modern software for the purpose of maintaining an older or previously supported feature.\u201d In […]\n","protected":false},"author":6,"featured_media":26650,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false},"categories":[22],"tags":[1209,1212,1211,1210,1208],"_links":{"self":[{"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/posts\/26641"}],"collection":[{"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/comments?post=26641"}],"version-history":[{"count":1,"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/posts\/26641\/revisions"}],"predecessor-version":[{"id":34045,"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/posts\/26641\/revisions\/34045"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/media\/26650"}],"wp:attachment":[{"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/media?parent=26641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/categories?post=26641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.wisdomignite.pt\/itv2\/wp-json\/wp\/v2\/tags?post=26641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}