[with apologies to Mr. Orwell]
I’ve noticed a subtle shift in how we approach building up new sites over the last couple of years. Our approach to site construction used to favor collecting open source apps and gluing them together in order to build up scaffolding quickly and to reuse the efforts of others. This is still a prominent part of how we operate, but we also don’t automatically reach for an app just because one exists — even ones we know are high quality.
In the past, pip requirements with dozens of dependencies was common for larger sites. These days we tend to use a lot more discretion before adding an entry to those files. While reusable apps can seem to offer productivity gains by providing the base for a feature with minimal effort, there can be a lot of hidden time costs that only surface intermittently throughout the life of a project (often at inconvenient times).
- Apps pull in their own dependencies, which you then need to manage.
- Some parts of the app provide exactly what you need, while others can be problematic.
- You’re only using a small percentage of the code provided by an app.
- The app maps well to basic use cases, but wasn’t designed for some aspects specific to your needs.
- Projects get stale or sometimes even disappear. You might have to make and maintain your own fixes.
- Many apps, while having nice APIs, won’t scale well out-of-the-box.
The problems come when you find what seem to be small incompatibilities and start working around them. We often have a tendency to defend solutions that initially seemed to work OK even as edge case complexity piles up. Over time you start accumulating a lot of technical debt.
This is far from advocating rolling your own for every site-specific problem. The great code out there is still great code and most of it is available under very liberal licenses. Pulling out the relevant pieces of code and massaging them to meet your problem domain can be a great option. Knowing which direction to go can depend on what stage in the project build you’re at. As you move further from the prototype, 3rd party dependencies should get more scrutiny.
More generally, some of this is based on the experience you gain from the pain of working through poor design choices. After you’ve learned the ins and outs of some aspect of internet applications, you have a keener eye about what potential solutions will look like. Whichever direction you go during your project build, having a healthy test suite will make for an easy transition should you need to ditch or replace a dependency.
