Dependency Avoidance

I don’t think you should totally avoid it, some third party tools are useful and allow the developer not to spend time developing functionality that already exists. I think someone mentioned a PDF generator.

The more dependencies the more potential problems with upgrades, migrations, etc. Maybe the server goes to 2003 and the third party component doesn’t work anymore. Now you wait for them to fix it.

Also, the more controls, the more libraries are loaded, more memory usage etc. It becomes a big headache, and you have to learn everyone’s API to use the control (some good some bad).

Here’s a good example of not using a library: Client wants reports in Excel format. Instead of using Excel libraries to create the worksheet and reports, we decide to create a CSV file that contains the data. Now, they might not get all the bells and whistles of Excel formatting, but any Excel client version will be able to use the data. If you use Excel API, you have to install Excel on the server to get the libraries, etc. Just simpler all around in IMO.

It’s funny to re-visit this topic in 2018, with the package explosion that’s happened in the last 8 years. Especially the front-end…if you working with any modern JS framework, just take a peek at your node_modules folder sometime :slight_smile:

I still agree with the basic sentiment (that’s actually why I came back to this article), but I’m looking at it more from a team-dependency perspective, vs just libraries. In many enterprise companies, one team cannot architect, design, develop, test and ship their code - that requires multiple teams, and those dependencies kill productivity IMO.

Continuous Delivery / DevOps FTW!

1 Like