😴 I'm taking a break from February 1, 2024 until May 1, 2024, so I will be less active here and on social media.

Build it yourself

January 20, 2022

When I build things, I often do so because I am stuck with a “build it yourself” mentality. That’s why I often advocate for building your own stuff as well (within reason). It’s not only good for improving your coding skills, there are also other benefits.

If there’s something you want to add to your application and you can feasibly build it yourself… you might want to. You’ll learn a lot, and you might be able to build something quite lightweight, because your constraints might be more flexible.

The Questions I Ask Myself

  1. Why not? Figure out why you shouldn’t build it yourself. Are there too many gotchas or edge cases?
  2. So what? Determine if you can’t build it anyway… perhaps not all edge cases apply to your use case?

Even more questions

At this point I’ve started work on the feature, or I’ve given up on building my own. Here’s the next questions you can ask yourself if you are not building your own, and are planning on using third party code:

  1. What and who can I trust? Find a suitable package or library that is maintained and trusted. Packages and/or libraries can disappear, you may want to create a fork if your code is absolutely critical.
  2. What has changed? Keep track of what changes when you perform minor and major version upgrades.

Things to look out for

Here’s a bunch of common red flags you might want to look at if you ship mission critical code and you use packages:

  • Third party code is often not inspected or understood. Instead of just using a package without worrying about how it works, consider its code quality and performance impact.
  • In order to accommodate more users and/or value proposition, functionality is bloated. This can be avoided, but it’s hard to say no if users are requesting more features and you’re making a product.
  • The code gets updated without review or audits frequently. Do you check the source code of all the packages whenever they change to find out what has changed? Trust is incredibly important in this context.
  • The code is linked to a specific version it was created for. In the context of a package, a framework version, for example. This can cause issues if packages are not maintained properly.

In reality, because of this vendor / third party code problem, we have frequent security issues with package handover, for example. It is not always feasible to do this every time, I do understand that. But if you are building e.g. financial apps, you might want to perform those audits, though.

Card House of Dependencies

Building your own stuff helps you avoid building a card house of dependencies, which is what I often see when I look at the Node.js ecosystem, which has been plagued by various security incidents over the years.

Thankfully, in the land of PHP we have a really great dependency manager. That being said, it is not impossible to end up requiring so many dependencies that aren’t yours that it becomes a bit overwhelming.

I am painfully aware of the scope of this issue though, and I understand it would be crazy if everyone had to write their own stuff all the time.

Underfunded & Harassed

In the same vein I am also painfully aware that certain open source software and/or packages are painfully underfunded… It’s tough out there, and I don’t think I’d want to be a full-time open source contributor. Here in Belgium, for example, the Ministry of Defense was under attack due to such a vulnerability.

Personally, I have been rather fortunate with the issues on my tool but I like to think that might have something to do with the comprehensive FAQ. Then again, even if your documentation is great, you might get harassed. Every now and then I see someone talk about a bad interaction, and that’s just disappointing.

Tagged as: Programming