This expensive trap is easily avoided by approaching problems from the right mindset. Not that long ago, I was working with a client who was using Kubernetes. Now, this client had started building their own custom tooling on Python to pull an application from their monorepo, apply a template to it, and output the descriptions that you run in Kubernetes. If you've used Kubernetes at all before, this should sound pretty standard. Because Kubernetes is declarative, all you really need to do in it is come up with these file descriptions of what the objects are that you want to create in your system. Once you've done that and given it to the cluster, the cluster will make it so. Now, the final versions of these descriptions are immutable. They can't be changed. Which means they don't support variables. If you want variables, you have to apply them beforehand. To solve this problem, this client's engineers had started to design their own tool to use. As I talked to them about their goals and what they were creating, I realized something. The tool they were spending so much time developing? It already exists. It's called . And they could have just taken Helm right off the shelf and had it do what they were trying to build. Helm When I brought this up, I was told that yeah, Helm does do all these things, but "we've already put time into developing ours". Theirs, he told me, was "a poor man's Helm." This belief that you have to keep working on something once you've already put time into it? That's known as the , and if you know anything about that, you know that it leads to losing even more money. sunk cost fallacy After that conversation, they spent the next two weeks with their team developing this "poor man's Helm," dumping something to the tune of $10-20,000 into it. And that's just development cost, not opportunity cost that could have been spent on other things. All that, and it still wasn't working quite a well as Helm would have if they'd just taken it down off the shelf to use it. So, they were pouring money into it, and trying to pass it off as the "poor man's" version. That isn't a poor man's version. That's a really expensive version. And not only that? It's one that ended up . not working as well as the available open-source tool This is an unfortunately common issue with some engineers. They get into the mindset that hey, they could make this thing, so maybe they should. But if there's a generic subcomponent available to use, there's a good chance that it already addresses the edge-cases you're likely to encounter. What you really end up doing is pouring time and money into something that you didn't need to. That's time and money that you could be spending on working around problems that you can't easily solve just by buying something off the shelf. Spending more money on something than you need to? That's not what poor people do. Poor people use open-source. Want to learn more about me, my agency Unbounded, and my stories? Check out my website here . Image licensed from Adobe Stock Images, by Lightboxx .
