
Legacy. The one word engineers cringe when they hear. Nobody wants to work with legacy code or legacy systems. And yet someone has to. Can we do something about it?



# The evolution of software

Let’s look at the evolution of software. It all starts with an idea. After some market research and market fit, a small team is formed to develop an MVP. The MVP then gets a few real users, which sets the ball rolling for team expansion and accelerated feature development. And as new features are being shipped, old features are becoming what we call legacy, and the backlog in Jira is getting filled with Tech Debts that are never prioritized because *We must develop this feature ASAP!*.

Eventually, the code becomes very hard to maintain. Most of the original authors already left the company and new engineers with enthusiasm to make the code a better place are met with criticism such as

1. This code is the core of the system, and any change there needs to be carefully reviewed by Amy's team. But her team does not have time for it in this quarter.
2. Nobody really knows what’s going on there. Dany was the last to work on it, but he now left for UniCo(rn) which raised gazillion dollars.
3. Yeah, we can do that, but maybe in the next quarter. We really need you to work on Feature X for ThisBigClient.
4. I'm in! Let's create a ticket in Jira Backlog and prioritize it in our next grooming!

And hence, their passion and enthusiasm slowly dies, until one day they become the ones who say the above phrases.

Legacy is the place where companies go to die.

# If you fear legacy — you are doomed to fail

Code is just a means to produce products. The harsh truth is that your code quality doesn’t really matter, as long is it produces the product that your customers are happy to pay for. And in a very competitive world we live right now, you don’t really have time to produce maintainable code. New startups don’t have time or resources to focus on code quality — they need to provide POC as fast as possible to acquire that one customer. Established companies already have customers who give zero concerns about your legacy code, and are mainly interested in features.

However, we are not in the 15th century, where you work as blacksmith your entire life, and the cost and time you will spend investing into your workshop will eventually pay for itself. In the modern world, people are not their companies. It’s very common for engineers to change jobs every 3 to 5 years. And investing in a “better code” will not benefit future you, because future you will work in a different company in few years. Same goes for your manager, his manager and your product manager. Even the most veteran people, who work for 10 or 15 years at the same place, will usually occupy a completely different position by the time you approach them to ask for help about the legacy they’ve written 9 years ago.

Because good companies will usually outlive their entire employees, legacy creates a big problem for them. If you want your company to be good, you must have 2 magic components:

1. Ability for new employees to support and maintain your codebase without hunting for knowledge from veteran employees or those who already left
2. Ability to innovate

## FooBaz Automobiles Inc.

I like to provide analogies from other industries, and I’m somewhat enthusiastic about cars, so here is one. Let’s say you start a car company and you rush your small engineering team to develop an efficient engine. Once your engine has been developed and you’ve provided a first prototype of your car, you begin to work on customer requests: better seats, nicer dashboard, more safety features etc. However as time passes, your engine starts to show its age.

Your new enthusiastic employee proposes to redesign the engine, but he is met with criticism: the current engine fits in the chassis we are developing; the engine is a critical part of the car; very few people know how the engine works and it’s better not to touch it; we promised our customers a big screen with navigation etc. As time passes, Acme Automobiles Inc is founded, and your enthusiastic employees are moving there, so they can innovate on their engine design, which proves to be twice as cheap and efficient as yours. And so little by little your company is phased out from existence.

Legacy code is like a viral infection. If you leave it untreated, it will spread and infect your entire codebase.

## Version 2

Another side effect of legacy is what is known as “*We can no longer develop new features in this codebase. It’s written in Ruby and it’s impossible to find any Ruby developers, so the Architects Council has come up with a decision to rewrite the software to Node.JS. We will call it V2*“.

And while a rewrite sounds like a good idea from an engineering perspective, it’s a bad idea from a product perspective. There are many nuances you need to think about when doing *v2*.

1. Are you going to hire an entirely new team to work on v2, or are you going to repurpose the existing team from v1 to v2?
2. What is happening to v1? Are you deprecating it? Are you going to invest development time in it? What happens to customers of v1?
3. How are you going to sell v2 to existing customers in v1? Nobody wants to move from a working product to a half-baked prototype with lacking feature parity.

V2s are great for engineers, especially those who are going to lead the development. You get to work with new technologies (usually), greenfield a product, the feature set is usually clear from the beginning (because you are essentially remaking an existing product, but in a maintainable way). In the end, after tears and blood, you get a new, somewhat maintainable, codebase with no legacy. But make no mistake, the life path of V2 will follow V1s - eventually it will become legacy. Because V2s are no more than a bandaid on the big “legacy infection” of your codebase.

# Oh no! What can we do?!

Have no fear! Legacy fighter is here.

The truth is — you can’t avoid legacy. I don’t believe in *problem prevention*, especially in software engineering. Problem prevention is equal to *magic crystal reading*. But this is a topic for another post. Let’s for now agree that legacy is the byproduct of software development. And the same way as a mess in the kitchen is a byproduct of Shabbat dinner preparations — it needs to be taken care of as soon as possible, before it piles into something you can’t handle.

This means that you need to have tasks that are **prioritized** in your sprint (or whatever system you use) in which you can tackle regions of code that are prone to become legacy. You don’t just fill your backlog with “*Improve X so that it will do Y*“ tasks and never work on them. You need to dedicate time. Find a balance between features and tech debts. Every sprint should have, let’s say, 80% features development and 20% tech debts. This also needs to be understood by your (a) Engineering Manager and (b) Product Manager. It must be a rule. There should be no exceptions. No “*but maybe in this sprint we can focus more on features since we really promised this client that it will happen”*. It’s not your problem, as a software engineer, that your product manager makes promises he can’t fulfill. It’s his job to balance the management of the product. Your job is to balance development of the product. And part of the development is making sure that your code continues to live after you decide to go to a different company; it’s your job to make sure that new developers are not faced with *oh no, this is a core functionality, we don’t touch that in our shire*.

Apart from **fixing** legacy, you need to make sure legacy is **identified**. Legacy does not just appear out of nowhere. Legacy is a good code that was piled on with a bunch of *quick fix for client* and *a patch to make it work in Explorer* type of development. Every feature and bug fix is a potential to identify legacy. If something is hard to understand, hard to work with — you need to document it. You need to make sure it’s known as a problem to the team, engineering manager and product manager. They need to be aware of the fact that you’ve tried to implement X but encountered a code that you’ve had to debug with other developers, because this code is hard to understand. And once they are aware of it, you prioritize it and start to work on it.

It’s an endless cycle. And it’s a healthy cycle. It’s part of development. And there will be sprints when you have a lot of features and very few legacy code, and there will be sprints where you have a big refactor to do and hence, you freeze feature development.

Legacy is not a boogie man. You don’t need to be afraid of it. But if you let it grow, it will grow. And will eventually kill your product and maybe even your company.


Legacy is where companies go to die


Take a good look at the following function and try to understand what it's doing.

```javascript
function do_magic(a, b) {
	return a + b;
}
```



Is it summing two numbers? Or maybe it's doing string concatenation? The answer is: you can't know. And this beats the entire purpose of programming languages – to be easily understandable by humans.

# A brief history of dynamically typed languages
There is a long [list][3] of dynamically typed languages, but for simplicity, I'll focus on a few of the most popular.

## PHP
PHP first appeared in 1995, and is officially categorized as a *scripting language*. It was created by Rasmus Lerdorf to maintain his personal homepage, which Rasmus wrote as CGI programs in C. It was never intended to be a programming language and Rasmus even said: "*I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.*"

It is now powering 78.1% of all websites, according to W3Techs report from January 2022.

## Python
First appeared in 1991. Its development started 2 years before that, in 1989, by Guido van Rossum. He was working with Amoeba operating system and needed a better language to do system administration, rather than writing C programs.

Python consistently ranks as one of the most popular programming languages.

## Lua
Created by Roberto Ierusalimschy, Luiz Henrique de Figueiredo, and Waldemar Celes in 1992, Lua was primarily designed to be embedded in other applications.

Today, Lua is the leading scripting language for games.

## JavaScript
Designed by Brendan Eich and appeared in 1995, JavaScript was created for one sole purpose – add dynamic capabilities to boringly static HTML pages.

Today, JavaScript is one of the core technologies of the World Wide Web and over 97% of websites use JavaScript.

---

As you can see, none of these languages were designed to be robust and replace the old C or Pascal. They all managed to find their niches, but they were all languages designed to either be used for personal needs, or with the main purpose of extending other applications which were written in statically compiled languages.

None of these languages should be used, in their pure state, as the primary languages for application development. Let me elaborate on that.

# The human factor
If you've ever worked on a serious project, you know that extending and maintaining it – is a challenging task.

How often you've looked at your code, or code you peer reviewed, and you said to yourself, “*What a nice, clean solution*”? But after a few months, when you've revisited the code, you thought to yourself “*How this piece of crap ended up in our code base?*”.

When we write code, we are unable to keep the entire context of "*why*" that we have in our head at the moment of coding; hence we end up looking at old code and crying. And the fact that we take away types – only makes things worse.

## One little bug
I remember hunting a bug in one of the system I was working on. The system had entities that were versioned, and the version was universal across the entire entity domain. Since the number of entities was huge, and with each entity modification, we needed to increase the version, we could easily overflow the 64bit integer. So we've decided to use BigInt column in the database to track the version.

For each create or update operation on an entity, we would call the following function:

```javascript
async function getCurrentVersion(howMany = 1) {
	const currentVersion = await magically_get_current_version_from_db();
	const nextVersion = currentVersion + howMany;
	await magically_set_current_version_in_db(nextVersion);

	return currentVersion;
}
```

*Note: I'm reconstructing the code from memory*.

The entire function was wrapped in a database transaction (to avoid race condition), and the “*magically\_\**” functions were actually calls to our ORM (please [don't use ORMs][4]) which would fetch the version from the DB, then reserve 1 or more (we could have batch updates) versions, and save it as next.

What we saw in our development environment was that entities were out of order, and we saw a considerable increase in version numbers. We've reached massive numbers very fast.

Just for an exercise, try to understand what was the problem. Continue reading once you've shed some tears.

It turned out that our ORM returned BigInt as strings. So if our current version in the DB was 123, it would come back from the ORM call as `"123"`, and adding an integer (let's say 1) to it, turned out to be.... *poopity whoopity*... `"1231"`.

I'll pause for a minute, so you could enjoy your moment of pseudo-superiority and express your nasty comments about my mediocre programming skills, because we all know that **you** write perfect code, and compile it in your head before V8's runtime even finishes interpreting it. 

My point is – it would not have happened in a statically typed language. No compiler in the world would just let you sum a string with an integer, or would at least warn you that you are about to do something stupid.

And yet, when I proposed people that we need to switch to Typescript, I've encountered comments such as: "*but I want fast iteration*", "*I had enough of Java headaches*", "*But then I have to define every type*" and my favorite "*But we don't have errors related to dynamic types*".

This bug is only one of many I’ve dealt with in my life. I don't have enough bits to count how many times I had to print objects just to see their contents. Is it `obj.foo_bar` or `obj.fooBar`? Not having types is like not having street names. You need to memorize the entire city and knock on each door and ask what street and what number is it. You have to keep the entire project and all of its dependencies in your head (and we all know that `node_modules` is like a black hole, so it can’t be kept in your head). Otherwise, you risk forgetting that some library decided not to use native `BigInt`, but instead return strings 🤷‍♂️.

# The cost of bugs
With the shift from desktop application towards SaaS software, and because of humans losing patience, developing software became a 24/7 task. You no longer have engineers who write code from 9to5, but you also have 24/7 on-call engineers (which nobody really [wants to be][5]) – hence the cost of such bugs is colossal.

Not only it harms your customers who cannot access your products; it harms your company, which loses money. And it harms you – because Murphy hates you, and it's your turn to be on-call. So, suddenly, you find yourself half drunk in a bar, on Friday evening, trying to understand why your BigInt is overflowing, while your friends take Vodka shots off your MacBook Pro. But hey, at least you don't need to define *EVERY TYPE*, like a bizarre monster who enjoys writing interfaces in Java.

# They aren’t made for it
None of the dynamically typed languages we are using in our production today are made to be used in such way. You keep hearing about how PayPal or Uber are switching to NodeJS, while forgetting about the fact, that their adoption of NodeJS is for a tiny API Gateway that proxies requests to their huge Java monoliths (probably; I've never worked in those companies, but I have 10+ years of software development experience, and know a thing or two about maintaining legacy code).

You keep embracing dynamic languages, while the world keeps deprecating them. Facebook developed Hack to introduce types into PHP. Even PHP now has support for types. Microsoft came up with TypeScript to ease the pain while writing JavaScript applications; Python 3 has support for type hinting; and surprisingly, but in Lua `"123" + 1` produces 124, and `"123" + nil` throws an error. Want to guess what's the output of `"123" + null` in JavaScript?

# It's better to be type safe than sorry
A world of fast iterations, race to market and other marketing terms – has no place for dynamically typed languages for business critical applications.

Don't get me wrong, dynamic languages are great at what they were designed to do. Python excels at AI and ML applications; Lua is perfect as embeddable scripting language for a type safe application; and JavaScript… it's still terrible, so please, at least, use TypeScript.

*Nah. I don't make stupid type related errors* – Well, go to your logs and search for how many `cannot read property x of undefined` you have. Chances are you have a few of those logs, and your code is scattered with `const bar = foo || {}` - because computers are made to be deterministic, but you are a free spirit and your `foo` *might* or *might not* be an actual object.

*I have tests to make sure I never sum integers with strings* – Well, guess what. If you had let compilers do their job, you wouldn't have to spend developer's time on writing guard tests for type related problems. Java developers don’t spend time writing tests to make sure `int x` is an integer.

Type safety is not some esoteric obsession of programming geeks in basements. It's **business critical** for every company that want to stay in business. And I'd even radically say to you, and ask you to politely tell your manager, that making your code type safe should be treated the same way you treat customer bugs, and not buried in a technical debt pile. Use type hinting, switch to TypeScript or a real statically typed language – I don’t really care, as long as you do it.

You owe it to yourself and your sanity. And if not yourself, then for the well-being of your company. And if not your company, then, *at least*, for the satisfaction of your customers.

[3]:	https://en.wikipedia.org/wiki/Dynamic_programming_language#Examples
[4]:	https://seldo.com/posts/orm_is_an_antipattern
[5]:	https://news.ycombinator.com/item?id=29368457


It's better to be (type)safe than sorry


It's that time again. You come to your Toyota dealership to buy a new Toyota Corolla. You've been waiting to upgrade your old, fuel inefficient and slow model, with this year's new model. But the new model is more fuel inefficient! Wait! What?!



The evolution of products is very clear. Newer should be better. Better equals more fuel efficient, faster, safer. Otherwise, why would you upgrade? Have you ever heard of your friend bragging about his new fridge, telling you how roomy it is, how it has an RGB light inside, but it uses more electricity? 😦

Or get this. Have you ever heard about a major airline, purchasing a new fleet of Boeing (or Airbus) airplanes, just so they will be less fuel efficient, make your flight longer and the airline needs to rebuild their hub airport because the airplane now can't taxi to the gate?

No, you haven’t. Because that’s not what progress is. Progress is a process towards better, not worse. You don’t buy a new car to drive slower or pay more for gas.

But you know what? In software, that is what we are doing. I’m writing this article, while Spotify is playing in the background, and a quick look at Activity Monitor reveals Spotify has 6 processes running, with an average of 2.2% of CPU usage, and a combined total of 470MB of memory usage! **470MB!!** Winamp uses around 49MB (with a VM size of 60MB) [source](http://forums.shoutcast.com/showthread.php?t=271869). And Winamp has **visualizations** ffs!

![Winamp visualizer {1200x675}](/images/winamp.webp "Wina-Winamp! It really whips the llama's ass!")

# Product Segmentation

I’m a developer. I try to have the best machine I can. Max memory, top CPU, best GPU (if I’m working with 3D graphics). We expect it from professionals. The same way professional car drivers try to get the best car; professional mountain bikers own the best bikes; pro photographers get the best camera and lenses.

But every product has segmentation. Some products are entry level, other aim at professionals. You can get a decent DSLR camera or an entry level mountain bicycle. And you can get an entry level PC or aim at a beefy machine with 64GB RAM and Ryzen 9 5900x (should you need that). But while your entry level DSLR will snap exceptional pictures, and your beginners mountain bicycle will get you through beginner singles, your entry level PC will struggle to keep up with basic software like music players or instant messaging.

# 640K ought to be enough for anybody

It’s Saturday and I’m on my home PC, so I don’t have Slack open, but a quick Google reveals that slack uses at max around 1GB of RAM. Add to it Spotify, a Chrome with few tabs, the OS itself and you’ve maxed out 4GB of RAM easily.

*But Slack is a professional tool!* - no. No, it’s not. It’s a glorified IM with slightly more features that mIRC. And mIRC uses anywhere between 50MB and 250MB ([source](https://forums.mirc.com/ubbthreads.php/topics/194177/Memory_usage)). Slack is used in a professional environment, yes, but it does not justify the fact that it eats a good chunk of my memory that I need for my professional work such as an IDE, running compilations and VMs.

We are in an era when software grows way bigger and heavier, but does not add any features or improvements. Spotify, for example, does not have an equalizer, a feature that Winamp does. Instead, it has friend’s activity, so I can see what are my friends listening to, because I have nothing else to do. Games used to be distributed on single CDs, then multiple DVDs and now you need to download tens of gigabytes over network in order to enjoy the last AAA titles. But with the increase in size and memory usage, we also got an increase in quality and visuals. We went all the way from rectangular faces like this:

![GTA 3 {970x546}](/images/gta3.webp "Busted")

To near realistic graphics like this:

![Witcher 3 - Wild Hunt {650x310}](/images/witcher3.png "Toss a coin to your Witcher")

*640k ought to be enough for anybody* - is a quote falsely attributed to Bill Gates [^1]. Although he never said that, and obviously staying within the limits of 640K is not progress, the current status quo is not acceptable! We can’t, and shouldn’t, argument everything with “*But RAM is cheap*”.

Today’s software gets heavier and ships with fewer features. There is a word for this process in the English dictionary: **regress**. It turns out that it is the antonym of **progress**.

# Why it happens?

Compared to 20-30 years ago, today software is everywhere. It’s even in your [fridge](https://www.samsung.com/us/explore/family-hub-refrigerator/overview/). Think of anything, and high chance it has software in it. And with a significant increase in software availability, a matching demand for software engineers came along.

And as with any factory production line, optimizations were made. New languages were created. From an old and clunky Fortran, where you write code such as:

```fortran
INTEGER(4) :: i,io_unit
REAL(8) :: pmin
STACK_PUSH
```

All the way to the new and shiny JavaScript where you write poetry:

```javascript
request(app)
	.delete("/something")
	.send()
	.expect(400)
	.end((err, res) => {
		err.should.have.proptery("message").equal.to("Bad Request")
	});
```

As something becomes more mainstream, it takes a simpler form. First cars were hard to drive, today you don’t even have to change the gears. Same with software. Back then you had to understand what are registers and how many bits your integers take. Today, everything is dynamic and the compiler or the runtime knows better than you what types to use.

While I struggle with this concept sometimes, because I grew up on understanding the difference between little and big endian; I understand the reasoning behind it. When a specialty tool is being adopted by the masses, it will be simplified to suit everyone as much as possible. As long as the adaptation includes improvements, I’m fine with it. This is progress, and the reason we, as humanity, can enjoy technology in the way we enjoy it.

Creating software today is simpler than ever before, with high level, garbage collected, dynamic languages and [block-like programming](https://developers.google.com/blockly). And the world of software creation opened a lot of business opportunities. You practically can create anything from nothing.

## A personal story

Around the age of 16, I had to choose a specialization in school. Once you reach 9th grade in school, you need to decide what specialization you want to get based on your desire and grades. There were specializations like psychology (focusing less on math and more on literature, psychology and philosophy); robotics (with focus on math and programming, and less on literature or psychology); computer science (with higher focus on math and programming, and less on literature and psychology) and others.

I was torn between robotics and computer science. I was sure it’s going to be the biggest decision of my life (boy, I was wrong). I remember the summer break between 8th and 9th grade, where I was struggling to decide what do I want to do, where do I want to go. I enjoyed creating things by writing code and my major struggle was to decide whether I want to create *virtual* things like software, or make software create *real* things like robots.

Programming was already a hobby of mine. And I choose computer science. One of the key factor for my decision was the fact that I come from an immigrant family. We are not poor, but I couldn’t allow myself asking my parents for money to buy resistors, breadboards and soldering station. I’ve already had a computer and knew programming and with that I could create software.

## Software production is *relatively* cheap

My "biggest" life decision boiled down to the fact that I had a PC. The upfront cost of software creation is relatively cheap. You don’t need to buy programming languages like you do with heavy machinery, nor you have to rent an office, like you do with a factory or a warehouse.

And the rewards you can get from software production are massive. We are in a midst of a software revolution, where VC funded startups are being spawned like zombies in Left 4 Dead 2.

![Startups are everywhere {671x372}](/images/startups.jpg "Look! Statups are everywhere")

## Nobody cares

Software surrounds us, and yet, in my opinion, it’s one of the inefficient industries we have. The solution to slow software is to buy more RAM or spin up yet another AWS instance. Ain’t nobody got time to figure out what’s wrong. Optimization became a hated word used by heretics. All our optimization problems are solved by increasing the instance type or instances count. In the end, everybody suffers and nobody really cares.

Users suffer. But they don’t care. They have nothing to do. Their choice is mostly between either using the product or not, or between two different software when neither of them is optimized enough or lack features.

Developers don’t care because it’s too hard to write proper software. It’s too hard to do proper error handling or debugging. They prefer to spend their time in creating [FizzBuzz](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition) architectures and appearing smart in front of their colleagues during design reviews. And their simple To-Do app is grown to a pile of shitty abstractions that nobody can understand how to debug and optimize.

![Oops, something went wrong {531x359}](/images/ops.webp#center "Imagine your car asking you to pull aside, turn off and then turn on because 'something went wrong'")

Business and VCs obviously don’t care as well. They care only about 3-letter-abbreviates such as TTM and ROI. The lower the first and higher the second - the happier they are. Tech debts are being buried beneath piles of optimization bugs that are fixed by occasionally restarting the servers. At least we do a retrospective!

When I type `google.com` in my browser, my computer issues a network request that, according to `traceroute` tool, travels between 20 different network hops and takes about 75ms to reach Google servers. **75ms**. Let that number sink for a moment. It travels between 20 different routers, most of them are with shitty (compared to your phone, yeah?) 1GHz CPUs and 1GB of RAM, serving millions of requests, via fiber or copper wiring, to a **different continent**! LET THAT SINK! And yet, it takes few **seconds** from the moment I open slack till the moment it’s useable, and I have fully spec-ed Mac Mini. 🤯

# The future

We had 4KB or RAM when we landed on the moon[^2], but today it takes **100000** more to send your colleague a message. Yes, RAM is cheap. Yes, machines are powerful. But progress is about doing the best you can. And I’m pretty sure that 400MB IM is not the best we can.

There is beautiful software out there. Efficient, snappy, feature-rich. There are engineers who care about performance, who care about getting the maximum out of the available technology. Not wasting resources. But they are in the minority.

Imagine a world where you can open a software and it’s useable right away. You don’t need to wait for it to load the redundant friend’s activity. It doesn’t have useless features. And it works on your entry level PC. Such a world is possible, and we are responsible for making it.

I encourage everybody to take an action. Refuse to write inefficient software. Demand time for Tech Debts that focus on optimization. Be open-minded and choose the best tool for the problem. Together we can fix the software industry.


[^1]: [Quote Investigator][1]
[^2]: [MetroWeekly - To the Moon and back on 4KB of Memory][2]

[1]: https://quoteinvestigator.com/2011/09/08/640k-enough/
[2]: https://www.metroweekly.com/2014/07/to-the-moon-and-back-on-4kb-of-memory/

The Software Industry is Broken

How to be a Great Technical Interviewer


We’ve all been there. Its time to introduce a new package / dependency to our code base, be it a HTTP request library, a logger or something else, and the question we ask ourselves “*Should I wrap it?*”



The main reason we ask this question is a hidden fear that maybe in the future we would like to change the underlying implementation to a different package. We, humans, like to keep our options open.

But in reality, by creating wrappers around your dependencies, you are actually narrowing down your options and limiting your self.

---

Lets say you use [axios](https://www.npmjs.com/package/axios) package and instead of using it directly, you decide to wrap it. Your wrapper will depend on axios and will expose some generic API that uses the internal functionality of axios.

You need to find the exact balance between what you want to expose and what you want to abstract. You don’t want to create a dumb proxy in front of axios because you want to keep your options open in case you decide to switch underlying functionality, so you try to create something abstract. And by doing so you encounter the first problem of wrappers:

> Wrappers take a feature rich library and dumb it down a set of simple functions

You don’t have time to create a proper wrapper. You don’t know what functionality you might need from it, so you focus on wrapping what you need **now**. In the end, you are making a product for your clients, not developing a library. You don’t have time to correctly wrap the underlying dependency. So you expose a few methods, those you need right now, in some abstract way, type *git commit* and go to drink your coffee with a smile on your face.

Later on, when one of your team mates needs to develop a new feature, he will happily look at your axios wrapper, expecting it to contain a method he needs and will be disappointed to find out that this method is not there. Now instead of focusing on delivering value to your customers, your team mate will have to focus on creating a useless abstraction for a greater cause of “*we might replace it in the future*”, and this brings me to the second and biggest problem of wrappers:

> Wrappers create the illusion of control. The main argument for creating a wrapper is that “we might change to a different underlying dependency in the future”, but guess what? No body, ever, changed from one logger to another; changed from postgres to mysql. And if they did, their wrapper probably caused them more troubles than help.

In programming there is a nice principle called YAGNI — You Aren’t Gonna Need That. YAGNI suggest that instead of implementing a bunch of abstractions with the hope that *“one day I might change the underlying implementation”* you actually focus on implementing what you need now. Don’t be afraid of refactoring — its a healthy process in software development. Focus on implementing **real** safety nets such as continuous automated unit and integration tests and look at type checking, either via statically typed languages or by using tools like TypeScript to help you with refactoring. Remember — wrappers create the **illusion** of safety, as they rarely help you with transition from one underlying library to another.

Donald Knuth once said

> The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; **premature optimization is the root of all evil** (or at least most of it) in programming.

Wrapping your dependencies is a premature optimization for a dooms day when you decide to switch to a different logger. This day will either never come or if it does, your wrapper will not save you from tons of refactoring and fixing broken tests anyway. And in the mean time, you’ve wasted time on creating your useless wrapper but instead you’ve needed to focus on proper refactoring and tools to help you with them (such as type checking), proper automated unit and integration testing while in same type enjoying the full potential of a library that’s been co-created by 260 different contributors (https://github.com/axios/axios/graphs/contributors), but hey! It is sure better to roll your own, dull wrapper, ain’t it?

---

So stop creating wrappers. Instead focus on refactoring (by prioritizing it as tech debt in your development life cycle), focus on tests. Focus on creating middlewares to common functionality that can be quickly plugged to existing libraries, instead of wrapping those libraries. Focus on bringing value to your customers instead of reinventing the wheel over and over again.

Software Engineering

Latest Posts

Legacy is where companies go to die

It's better to be (type)safe than sorry

The Software Industry is Broken

How to be a Great Technical Interviewer

Wrap your gifts not your dependencies