Why Use Existing Solutions If You Can Build?

Whatever technology your business needs, you have a choice between developing a solution in-house, which takes time and resources but is bespoke to your business, or using an off-the-shelf solution that provides instant value but may need some configuring to fit your needs. Our CTO Boris Marn shares his experience in the tribal world of software development and why it’s better to take pragmatic approach to these decisions.

I still remember when I was in college, and we had discussions and disagreements about which language is better – C or Java? These were important disputes for our 18-year-old brains, and given that we had arguments when we were 12 over which mobile operator is better, I guess this was a natural advancement in my life.

C or Java?

From the start of these disputes, I didn’t offer any opinions. Most prospective computer scientists had already started programming much sooner and I was a complete beginner. The whole theme sounded like something I had heard many times in middle school—people arguing about which car is better and me trying to pivot to some more interesting topic.

But given that a lot of people around me had these discussions and I was becoming a developer, it was bound to happen that I would have an opinion eventually, even if I never used C.

I still remember all the reasons given for why C is better:

• It appeals more to the soul as you understand the internals more.
• There is no magic garbage collector or VM that makes you lazy.
• You write more things on your own and learn more that way.
• Results are more predictable (sometimes garbage collection reduces speed unpredictably).
• You experience the joy of creating your own linked list if you need it (or something else).
• It’s much faster. It’s for real programmers!

C fans were, without exception, Linux fans, and Windows was seen as a bad operating system with predatory monopolistic behaviour.

I naturally gravitated towards Java because every time I tried Ubuntu or another Linux distribution, some things only worked partially, and I simply did not want to spend time learning how to make buttons on a mouse work. If C fans like Linux and you hate Linux, then naturally, you love Java, don’t you?

I spent the next 12 years developing in Java. Working with people in the Java world, there were no disputes about which language was better, as we were all using Java. However, within this community, you could still see two different types of people doing the same work.

Pragmatics versus Fundamentalists

One group cared a lot about how Java works, it’s structure, the programming language and its internals and how to use Git from the console.

The other group, which I considered myself part of, cared more about libraries and using them to build a great solution than the process. I read the Spring Framework documentation (a popular development framework of the time) several times, and with every new version, I was excited about how much easier and more elegant the future would be.

I still remember vividly when one of my teammates looked at me weirdly and asked why I used a library to do things I could write on my own. Am I not a real coder who likes writing stuff? Why am I using an existing solution if I can create my own, which I am sure will work as I’ve written it, and I will always be able to change it?

These two groups were everywhere I worked. I even started naming them! One group I called the fundamentalists and the other, the pragmatists. 

I can give many good reasons why pragmatists are better, to defend my own bias:

• Maintenance of other people’s code is a hassle. It’s better to write less code and use existing solutions/libraries. 
• One way or another, you are captive to others’ work. The only question is whether you will be captive to popular libraries supported by a team or community of developers or to your own developers who created solutions years ago and are now somewhere else, having grown tired of maintaining their own frameworks.
• I don’t want our code to be held hostage by an architect who is no longer working on the team.
• I am not a fan of going deeper if I don’t have to. And I don’t feel like I need to reinvent the wheel.
• The IKEA effect (a cognitive bias in which consumers place a disproportionately high value on products they created) you think your solution is better and other people’s solutions are worse! This is why you think your reasoning is better than mine.

The fundamentalist group mostly wanted to build things on their own, while the pragmatists were more concerned with the end solution.

Can you afford to be fundamentalists?

If you look at companies like Google or Meta, you can see that the fundamentalist approach works best. Big tech can afford to hire more engineers than needed. They can invest a lot of resources into failed products without being labelled as failures. They can afford to contribute to the open-source community. Their applications are meant to handle a scale that most companies never have to experience. The situation in big tech is different from that in most other companies.

In smaller companies, where cash flow is much more important and good engineers aren’t in abundance, companies simply can’t put 100 engineers into developing something that already exists on the market.

I’ve seen companies that became too entangled in doing things from scratch that already exist while this is not their product, and the consequences were always bad. The time to create your own working solution was always underestimated, while the time for maintenance was not considered.

Being too fundamentalist in a solution-based company led to slow development, unproductive debates, lack of trust due to numerous bugs and misunderstandings between product and engineering, people leaving, and waning support from management. This eventually leads to either a complete rewrite or a dead product as development became so slow and nobody wanted to deal with it.

A lesson for business not just developers

It wasn’t only in development where I’ve seen this pattern. Some design teams spent too much time on design aspects that are not the core of the product, like payment processing, resulting in deep dissatisfaction from development and project or product management.

When deciding what to focus on, maximise your own solutions where your company is producing value and minimise self-made solutions when they are not part of your core business—especially if better solutions already exist.

The excitement of greenfield projects can lead to dissatisfaction, an apparent lack of strategy, loss of internal trust, and projects failing to meet estimates.