From Not Invented Here to Never Invented Here
ayasin
534

“ If something will take less than an hour or 2 to code and test, don’t even bother looking for an existing solution outside of the existing set of libraries you’re already familiar with or using. Just get to work and write some code.”

Really? JavaScript has no native framework like Java or .NET. You have to create, or borrow, just about everything. An hour or two times the hundreds of such things that make up substantive code is actually a lot of time to throw away. And any seasoned developer knows that it’s foolish to think that every simple function such as a left-pad is a “one and done” that you’ll never have to think about again. All the flawed implementations that all the clever jacks threw out there in response to this dust-up prove that. They nearly universally fail the unit tests of the silly npm version because they don’t handle edge cases such as non-string values, or they don’t allow omission of the padding character argument. Yeah, trivial stuff. So maybe it’s three or four hours and not one or two. Or maybe that edge case doesn’t come up until a year later. This is, actually, what technical debt is made of.

Beyond that, there’s a big long-term cost to developing everything in-house: consistency. You have unique versions of every single little helper that you’ll ever need, which now all your developers have to learn. And, you need a way to share it among all your applications in-house, and evangelize it, or have more than one version of each of those things floating around. Now you’re looking at a cost of (an hour or two *each developer * each project * each function). How will you mitigate this? Will you create a custom uber-library for just your shop? Will you version it? How will you distribute and organize it? Suddenly an hour or two becomes kind of a thing.

So rather than doing that, why not just use some well-heeled common implementation that’s already out there, that’s already tested, that’s already had the edge cases considered?

So I have exactly the opposite philosophy as you. If it’s something that would take just an hour or two to code and test (assuming I got it right the 1st time, which you don’t always), then it’s simple enough that I have almost no risk from using someone else’s code. I can completely understand it’s purpose, functionality and API with very little effort. I can easily replace it in the future if I need to. And frankly, I’d rather spend my time creating code that adds value, rather than re-implementing some mundane algorithm and writing unit tests for same.

On the other hand, I would think long and hard before integrating some big wonder-module with lots of moving parts and grandiose functionality. Sure, it could solve all your problems, but the first time it doesn’t do exactly what you want, you’re looking at reverse-engineering, or patching, or hacking, or working around… and by that time you’re so tightly coupled with that big thing, you can’t easily just use something else. Because it’s big, and you depend on that bigness as a unit.

Don’t be a brickmaker. Be a mason.

Show your support

Clapping shows how much you appreciated James Treworgy’s story.