The Cost of Doing it Yourself

There is a fantastic talk given by Lee Campbell on The Cost of a Dependency that outlines the hidden and often overlooked cost of adding dependencies to your software project. He makes a compelling case for minimising dependencies, however, what happens when we go too far? The following are not straightforward yes or no answers, but will hopefully help you think about:

What is the cost of building it yourself?

Cost #1: Build Time

The first, and most obvious cost of building it yourself is, well... building it. Let's be frank for a minute. If you think your work AWS bill is expensive, have you taken a look at your engineering salaries? At least with AWS those resources are (normally) only charged when they're doing something useful for the business. So when building something you should be thinking

Am I contributing to this company's goals or am I acting like a very expensive rds instance in dev that we forgot to turn off?

On top of pure salary cost, there's also the Opportunity Cost. Every day you're working on building thing x is time that perhaps you could have spent on something for your product owner.

But I was working on fixing up tech debt anyways so the PO isn't losing any resources.

Is this really the most valuable use of your time when compared to deleting code, improving build times, or working on that PIR action from 6 months ago you promised to do.

Cost #2: Maintenance Time

Most of us are working on systems that could likely outlive our time at the company. After we've built a new system we need to think about:

• How do we find and fix security issues?
• How do we deal with software updates?
• What if we need to extend this software?
• Am I comfortable owning this? If not, then who does?

While using dependencies means you're at the mercy of the supplier, if you build it yourself you're at the mercy of well..yourself. If you need a new feature you have to build it. If there's a breaking change in your runtime you have to patch it. If you've allowed another team to use your software then who fixes it if there's an urgent issue?

Some of these problems are valid if you're working on sections that give you a lot of business value and competitive advantage. For example, if you're creating a ticketing website then the complexity around assigning and verifying tickets is likely one that you want to own and focus on.

But if it's not critical to your team's success then are you ok paying all these costs?

Cost #3: Lead Time

So let's say we've paid the upfront cost of building it, and we have even been maintaining it for a few months. Well, what has it given us? These new systems we create are often built under the notion of "oh we can work so much better with our solution x over dependency y and we'll ship even faster" but this is not always true.

Adding functionality

Does our new system allow us to add functionality faster or with more quality? If the software does not achieve one of these things then it is just adding unnecessary complexity.

Adding people

How easy is it to upskill people in this custom-built solution? This, in my opinion, is the biggest cost of building it yourself. I've seen solutions built from scratch with great intentions however a few years later (remember how we're building long-lasting software) no one on the team who built it is left around. This means people become scared to maintain it, add to it, or even rip it out. To combat this we need to ensure we have good documentation that evolves with our solution, something that most dependencies will give us for free.

When should I build it myself?

Despite all these costs, there are plenty of situations where you should build a software solution yourself, the main one being if it brings your company a competitive advantage. The reason for thinking about the costs is actually to ensure that you're focussing on the most important parts of your system.

Conclusion

The cost of a dependency can be higher than expected, we are relying on others and adding code that we (likely) didn't write to our systems that can inflate build times, local dev experience, add security issues or just make debugging and observability a nightmare. This may lead us to try and build everything in-house however this road is also littered with costs as I've shown above. The real solution is somewhere in between. Some organisations may be 100% ok with taking the costs (ie Google uses a lot of in-house software), but most of us should focus on what gives us business value and spend less time on what doesn't.