How to Avoid Costly and Time-Wasting Mistakes when building software

Engineering teams make decisions every day.

These decisions have a direct impact on how software is built and evolved.

They dictate whether a project takes 12 or 3 months to launch, or costs $300.000 instead $30.000 to achieve the same outcome.

Contrary to building a house, there’s no blueprint when it comes to software development. There’s no “it’s done” state.

But what decisions are responsible for slow and costly software development?

Not Invented Here (NIH)

That’s the most common mistake. Teams avoid using existing technologies and products to solve problems and instead decide to build custom solutions in-house. It is exciting and challenging for the team, but it becomes a nightmare for the business.

Typical examples include:

1. Building a custom CMS: The team decides to build their own custom content management system (CMS), even though there are many widely used and well-established CMS platforms available.
2. Refusing to use a payment gateway: The team decides not to use a widely adopted payment gateway, such as Stripe or PayPal, and instead builds their own custom payment solution.
3. Building a custom BI or analytics platform: The team decides to build their own custom analytics platform, despite plenty of popular platforms around.

The side-effects of the “Not Invented Here (NIH)” approach are negative to the business.

The team spends time building half-baked custom solutions that are not part of the business core (what only the company can do). In the short term, it means delaying the development of the core areas. In the long term, it means spending an ever-increasing amount of time maintaining these projects, instead of evolving the product.

Kubernetes

Kubernetes is a platform for managing and automating the deployment, scaling, and operations of application containers.

For most companies, Kubernetes is overkill. A really expensive and time-consuming one.

Kubernetes is designed to support large-scale, highly-available systems, which are typically deployed by large enterprises.

Why should a company looking for product-market fit use it? It shouldn’t.

I’ve seen multiple companies, with teams spending months setting up their Kubernetes infrastructure, instead of working on the product.

There are simpler ways to support architecture automation and scalability. Kubernetes is definitively not the first option. Nor the second.

Microservices

Microservices is an architectural style where a large, complex application is divided into smaller, independent services that communicate with each other to achieve a common goal. It’s a useful strategy when a company needs to evolve different parts of the software in different teams and paces.

There are high operational costs when adopting the microservice architecture. This cost slows down the development team. For that reason, it’s wise to build new applications as a monolith initially, even if it may benefit from Microservices later.

A/B tests

A/B tests are experiments in which two versions (A and B) of a product or feature are compared to determine which one performs better.

In theory, it seems like a great way for new products to make “data-driven” decisions, based on the outcomes of these experiments.

But the reality is different.

In order to draw meaningful conclusions, you need a considerable sample size. That means traffic to your product. Without that, the results of an A/B test will be unreliable.

Imagine the following example: you want to test different CTA (call-to-action) on your homepage. Consider you have an existing 5% conversion rate. You’ll test two different variations besides the existing one. Your homepage gets 200 visitors every day, and all of them will be part of the test. How many days do you need to run a test to draw a conclusion? 114.

114 days for a single test, without any other change to the homepage, doesn’t look like a quick way to improve things. Still, teams will spend a lot of time and money integrating with A/B tools to achieve that. Or even worse, they will build their own A/B test tool in-house.

Summary

To avoid costly and time-wasting mistakes when building software, keep these 6 tips in mind:

1. If your software development team is considering using any of the topics above, be worried.
2. Make sure the software development team has full visibility and knowledge of the business priorities.
3. Before building any internal tool, evaluate 3rd-party options that can achieve the same.
4. Unless you are a big company, with a dedicated DevOps team, do not even consider using Kubernetes.
5. Microservices don’t solve performance problems. It’s an operational pattern, to enable multiple teams to work together. Unless you have a complex application and multiple teams, you don’t need it.
6. A/B tests look like the holy grail of data-driven decision-making. But unless you have considerable traffic, the results are unreliable and misleading.