I’ve written about avoiding technical debt before, and probably will do so more in the future. There’s just so many ways to avoid it or at least limit its consequences. At the very least, you should be writing automated tests. But let’s look at another way to avoid technical debt: no writing the code at all. Am I joking? Not at all!
Technical debt inevitably starts accumulating early on in a project. Either corners need to be cut, or situations change. This leads to different kinds of technical debt, but it’s inevitable that your software will end up with pieces of code that you feel require refactoring.
Your Core Business
If those pieces of code are central to your business, then that’s fine. As a company, you should stick to your core business. This is where you make the difference. This is what you know best. It’s where you shine in contrast to your competitors.
So this is code that you can’t do without. There’s no replacing it with something else. Otherwise, you would just be using your competitor’s code.
This is the code where technical debt is allowed to accumulate, though you should also keep a close eye on it and take time to reduce it. It’s a constant struggle of adding new features, improving existing features, and keeping the code clean and maintainable.
But it’s code you can’t do without, because you’re probably selling it.
Side Concerns
Where things get tricky, is code that is supporting your core logic. Things that come to mind are:
- logging frameworks
- database interaction (also known as ORM’s)
- monitoring/alerting systems
But authentication systems, web frameworks, middleware, algorithms and security libraries are also things that are probably not your core business. Most teams will just take an off-the-shelf solution, especially in smaller organizations.
Larger enterprises sometimes have a tendency to implement these themselves.
Here’s why this is a bad idea.
Code Costs Money
Every line of code your organization writes, is a line that needs to be tested (automated or manually) and supported. It just adds to the inventory that needs to be maintained and updated.
This is costing you money because you’re paying developers to do the work. There is also an opportunity cost, because this developer could be putting effort into improving your core business logic, which is what you’re selling.
So what should you do instead?
What’s The Alternative
Instead of implementing the side concerns yourself, have a look on the internet what’s available that will work for you. You should probably set up a list of requirements, because not everything you will find is of the same quality. You’ll want to think about the available support, ease of implementation, popularity, security and cost, for example.
Objections
You might have certain objections to this logic. Let’s look at some popular counter arguments.
Vendor Lock-in
If you choose a certain product to implement a side concern, you might be afraid of vendor lock-in. You will have to integrate your code with the API’s of the chosen product. And you might not want to be stuck with this system in the future, with no way of switching.
But here’s the thing with code. Whether or not you implement it yourself, you will always have a certain degree of dependency. This will make a switch in the future difficult, yes. But there are ways to mitigate this, though not eliminate it entirely.
Also, in my experience, a switch is seldom done in the first few years after integrating the product. And moving away from an external vendor’s product is usually as much effort as moving away from a custom solution, if not less!
Cost
What if the home-made solution costs you less to develop than buying a product from an external vendor? As I explained above, the cost is not merely the time your developer spends on the implementation. There is a total cost of ownership that includes support, bug-fixing, updating, documenting, etc. These are costs not known up-front. But they will return yearly, monthly or even weekly.
When the original developer leaves (and they will leave), you will need to onboard a new developer so that they can maintain the existing code. Costing you time and money again.
With an off-the-shelf product, you might still need some tweaking and configuring. But if chosen wisely, there’s a team and a company behind the product. Which means bugs, documentation, updates, etc. are not your concern.
Yes, buying a product also comes at a cost. But it’s a more foreseeable cost at least. This allows you to incorporate it into your yearly budget.
And these days, you can find a lot of great solutions for free as well!
Buy Instead of Code
So if you can, take an existing product that fits your needs, instead of implementing one yourself. Focus on your code business. You’re probably not writing your own database, are you? So why would you want to write your own logging framework? Or alerting system? Or whatever it is that you can replace with a decent third-party product.
Write the minimum amount of code to integrate it in your processes and let the external vendor do the heavy lifting. This will save your time, effort, and money. And in the meantime, you can focus on improving your unique product and getting ahead of the competition.