Never spend an afternoon programming something that you may have to waste future time debugging and supporting when a dependency already handles it perfectly.
Never use a dependency that you could replace with an afternoon of programming
191–200 of 333 posts
Re: Never use a dependency that you could replace with an afternoon of programming
#192Earlier quoted context omitted.
They failed at writing a correct O(n) left pad in their benchmark: https://github.com/left-pad/left-pad/blob/master/perf/O(n).j... They are repeatedly appending a single character to the front of a string. This is actually O(n^2) so of course they are winning against it.
That would depend on the underlying implementation of the string object, no? (If the string is implemented as a linked list it's O(n)) Anyway, it makes no practical difference in this case, since the one they labeled "O(n)" is the naive implementation that most people would write if they implemented left-pad themselves.
String implemented as a linked list.
You’re a webdev aren’t you?
Re: Never use a dependency that you could replace with an afternoon of programming
#193My rule is, don't use a dependency to implement your core business. Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions. Everything else you write is just fat waiting to be cut by someone who…
> don't use a dependency to implement your core business In logic language, you're saying "If X is your core business, don't outsource X". > Is JSON parsing our core business? No, so why would we ever write -- and thereby commit to supporting for its entire lifetime -- JSON parsing code? All the code you write and support should be directly tied to what you as a business decide are your fundamental value propositions…
Since we're in pedanticville, these aren't converses, but inverses. The converse goes "If you don't outsource X, then X is your core business".
Re: Never use a dependency that you could replace with an afternoon of programming
#194I once decided to write my own UI pagination component. I thought it would be fun and, why bring in a library for something so simple? Three years later, we now use this component for all our pagination. Probably four of us know it really well by now as it turns out, there have been many bugs around it. Turns out pagination was not such a trivial problem to solve when you consider all the edge-cases and crazy PM requirements.
Every once and a while some engineer who's fixing a bug on it will ask, "why in the world did we write this? Why don't we just use this bootstrap pagination instead?". I ask in return, "would it fix the bug you currently have with it?". Every single time the answer has been no. It's almost always centered around the state of how the parent component is using it. I wrote with the intention of using querystrings to store pagination state in the url, but someone else at some point decides to store their pagination data in memory and just adds a few props and now it's doing it two different ways, etc...
I think the criminal offense here was not writing pagination from scratch. It was that I didn't extract it into a library and write some basic documentation.
Re: Never use a dependency that you could replace with an afternoon of programming
#195> Many times, the best approach is first searching online and reading the code to a few other solutions, then writing your own with the knowledge you’ve gained from seeing how they work.
I think this is a great approach. Any general solution library will be much larger and more complex than one project's use case. Seeing how other people have solved a given problem can give a dev a nice jump start on creating a compact solution to their given problem.
For whatever reason many devs just love using dependencies and almost always underestimate the long term costs, in terms of maintenance and vulnerability risk.
I once had to write a simple utility script that was literally 5 lines of Python. All it did was loop through a list and perform a couple simple actions. As I mentioned it to the PM, another dev jumped in and said, "Oh hey, there's Library_X that we can install that will totally handle that for you". I responded that the library could very well be great, but script was already done, had only taken about 15 minutes to write, and would be very easy to reason about and update down the line. Reading about and implementing a whole new library to do the same thing just didn't seem useful.
The other dev sounded unconvinced.
Re: Never use a dependency that you could replace with an afternoon of programming
#196BRB, going to go roll my own AES -- what could possibly go wrong?
Re: Never use a dependency that you could replace with an afternoon of programming
#197Earlier quoted context omitted.
I came here just to say this. "This'll take an afternoon" - three weeks later...... Programmers are notorious for this. BUT even apart from this problem ... you absolutely should use every dependency you can that will save you time. Try to write less code not more. When you write code you write bugs, add complexity, add scope increase need for testing, increase the cognitive load required to comprehend the software,…
> "This'll take an afternoon" - three weeks later...... > Programmers are notorious for this. From my experience with these personal failings, the problem usually comes from the question being phrased in the context like, "before you begin working on this, how long do you think this will this take you to complete?". If there's no opportunity to scope, with requires not insignificant work towards the solution, the est…
I recently read through the (free online) 'book' on Basecamp's 'shape up' methodology; I thought the 'hill chart' describes this really well - the work needs to be in progress going up the hill discovering what it's all about, before you get to the top and can accurately assess how much 'real work' (!) there is to do, and then it's all downhill from there.
Re: Never use a dependency that you could replace with an afternoon of programming
#198Earlier quoted context omitted.
A simple example would be an HTTP client. It’s easy to write a naive thing that makes GET requests with no request body, TLS, connection pooling, etc. Why should I use a dependency when I can write it in an afternoon? Well, I used to think that before I tried writing one :) The first draft was easy. Adding features got messy.
I had the opposite experience. All I needed was a way to do a simple GET. That's it (and that's all it still is, by the way). Instead of spending half an hour writing the code, I decided to use libcurl---that's what it's for, right? Until I found it wasn't installed on some of our test machines (it was needed for testing, not for production and for reasons beyond my pay grade, libcurl was not available on the machine…
If your needs are tightly scoped, I agree that a tiny one off thing is fine.
Re: Never use a dependency that you could replace with an afternoon of programming
#199It's a matter of judgement, but here's a few observations: - With a little experience, you know what gets fiddly and what doesn't. Today for instance, I needed a way to remove tags in an SVG document, which looks a lot like HTML tags. I quickly ended up finding that Regex is not the solution (a well known guy on SO wrote an answer that looks like a huge warning sign). I also couldn't enumerate all the corner cases. S…
Depending on Boost is not a good idea unless there is no alternative in the standard library nor easy to implement.
Re: Never use a dependency that you could replace with an afternoon of programming
#200Earlier quoted context omitted.
Or just C&P the relevant open source code (license allowing). Removing a dependency doesn’t have to mean writing from scratch.
If you copy the code into your project you at least need to keep track of the original authors and licensing or you're in violation of the copyright 99% of the time.
Oh, of course. Definitely.