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
- Why not? Figure out why you shouldnât build it yourself. Are there too many gotchas or edge cases?
- 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:
- 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.
- 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.