Matt In Code

npm install

Let me start by saying that this post is not about bashing npm, they are fine, really! 🙂 The problem is not npm but how we as developers use code through package managers like nuget, npm etc.

The problem is that we as developers deceive ourselves to believe that installing a package will solve a problem or fill a missing piece in the puzzle. In my experience the opposite is true in almost every case. I’ve been working with 3:rd party software with or without access to source code for 20+ years. Way back we used different reporting components (Active Reports, Crystal Reports) and in later years different UI-frameworks for WPF/Silverlight and the web.

What end up happening is that we try to bend the different frameworks and components to the customer requirements. Trying to make the software to do stuff that it was not designed to do is a recipe for failure and frustration. Also trying to fix bugs in the components by making workarounds, often by trial and error or in some cases tedious introspection. Often the suites are built to cover 100 different use cases and we maybe have 10 that fits the bill.

A real life example

Recently in a large web project (using react) we started to use some different components to “save time”. An investigation was made into the different components to pick the best candidates. The investigation consumed a couple of man weeks in total.

Then the coding started and components was used in a couple of views and the first issues started to appear. Workarounds was built to fix some problems, pull requests issued and more code was added in an attempt to add missing functionality. The missing functionality was stuff that was imminent to release on one of the components at the time of investigation. This component was suddenly abandoned due to the maintainers decided to start work on version 2 with a different approach. The new component was missing 90% of the functionality of the old one.

A lot of time was put into fixing browser compatibility and other issues. I decided to rewrite one of the smaller components where we reached a definitive dead end. It took 3 days including some bug fixes and I had a lot of fun doing it. The 3 days was a fraction of the time put into bug fixing and the initial investigation of the 3:rd party component. Of course I only implemented exactly the functionality we needed hence making a much smaller footprint than the “external” component and therefore fewer lines of code that could cause bugs.

Some weeks later we reached a similar dead end with the biggest 3:rd party component (a grid with advanced features). There was several issues that couldn’t be done by “monkeypatching” and we didn’t want to fork the component due to maintenance issues. There was also performance issues and feature requests from the customer. Once again I rewrote the component from scratch. Within a week the same functionality as the old component was in place, another week and the missing functionality was added. It took in total 3 weeks to implement current functionality + new features and bug fixes. Once again, we had put in the same amount of time just doing tedious bug fixing on the 3:rd party component.

This is not the first time in a project that I’ve had a similar experience. It looks tempting to use of the shelf components but in most bigger projects it ends up killing creativity. I much prefer building stuff that does exactly was it’s supposed to do and nothing more.

The package

What’s behind the packages we pull down? Most packages are built by a single individual. For some fact-checking go to the github-page of a component, then click the “Contributors”-tab and check the commit frequency of the developers. Even some of the bigger packages that have 50+ contributors only have one developer that do most of the work. When that lone developer lose interest the component is dead, no more updates to fix issues when frameworks move forward.

Security

Today there is tooling in npm for auditing packages which is nice but it’s far from perfect. There has been more than one example of malicious code in npm packages that auditing has not detected. What makes it hard to overview is that even the simplest packages has dependencies on other packages.

Conclusion

This post is not about stop using package managers or re-inventing the wheel. Next time you need some functionality and starts googling spend some time thinking on the problem first. Is there a simple solution to solve the problem you have? Do you really need all the bells and whistles that some component come with or is that just extra baggage (and more bugs)?

It’s fun to solve problems, it’s fun to write code…

Happy coding!

Way back before social media was invented I had a blog, well several in fact. The content was primarily for my own use but corporate firewalls and bad internet connections made it easier to put all content offline instead.

Today the only content I put online (mostly in private repos) is on GitHub and GitLab plus some tweets here and there. At work we use Yammer extensively where I do put stuff that I find may be useful to other developers inside the company. In my team we use Teams (yeah we are mostly a Microsoft shop).

For anyone outside the company I’m a Dark Matter Developer as Scott Hanselman like to put it. I’ve reflected on this for several years but a very nice talk by Troy Hunt at NDC Oslo really made the coin drop, “cheesus I’m invisible”. This motivated me to start being more public and this post is just the beginning.