8 ms·

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 ...

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, introduce the need for documentation..... there's a vast array of reason to use existing code even if you truly could estimate it and build it in an afternoon. You also assume that you understand all the edge cases and fickle aspects of the dependency, all the weird ins and outs that the dependency author probably spent much resources understanding, fixing and bug hunting. There's a hard fact that proves the above poster to be wrong..... how many dependencies took only an afternoon of time in total to write? Hard to say (maybe look at the github commit history) but I'd guess almost none. It didn't take the dependency author an afternoon, so why will it take you an afternoon? Even worse .... you just lost an afternoon coding features for your core application. Multiply this by every dependency that "you could build in an afternoon" and you'll be in Duke Nukem Forever territory. I'd advise doing the opposite of this articles suggestion. Find a dependency that will save you an afternoon? Grab it.

vlovich123 6y ago
Depends how your dependency management system works. Some times it can take an afternoon or more just to integrate it into your build for c/c++
- avmich 6y ago
  Somehow here we assume a good programmer routinely makes errors in time estimation by an order of magnitude, yet conveniently forget cases when, say, a non-trivial GPL library is embedded as a dependency into a project, and customer is asking for code, and legal team runs with hairs on fire because company didn't plan to release the code...
  - greyhair 6y ago
    But that is a completely different topic. Licensing is an issue, yes, but that is part of the upfront decision process. In this day an age, this many years into open source licensing, if your team is not on top of that from day one, they have failed as a team. I worked at Bell Labs from the mid 1980s to 2000, and by early 1990s (1992? 1993?) they already had a full internal team dedicated to open source licensing issues, including training and consulting. That was 27 or 28 years ago. Before some of the developers on this thread were even born.
scrozart 6y ago
Exactly. I'm not reinventing the wheel. I may write some convenience wrapping around Spring Security, for instance, but why would I rewrite auth-z when it's a solved problem?
avmich 6y ago
> you absolutely should use every dependency you can that will save you time > Find a dependency that will save you an afternoon? Grab it. Agree. The point of the article, though, is that dependencies are often saving much less time than they promise - so much less that it's better to avoid them.
ori_b 6y ago
And when you run into a bug or design problem in a dependency of a dependency of a dependency? It often takes less time to write some code than to understand someone else's code. Most programmers I've worked with get lost easily when jumping through layers of other people's code. I certainly do. Solid, well tested dependencies that solve hard problems are worthwhile. But dependencies have a cost in debuggability and maintenance, so it's worth using them with care. And often, they aren't worth the time, when compared to writing a dozen lines of code.
- eberkund 6y ago
  I get easily lost jumping through layers of code written by corporate developers in an afternoon. I generally don't have problems jumping through layers of popular, well documented and single-purpose third-party libraries.
- quest88 6y ago
  Cross that bridge when you get there.
kjeetgill 6y ago
While I agree that if you think it'll just take an afternoon, for the sake of this article it had better! But conceding that charitable assumption to the article, I agree with its basic premise: dependencies cost a lot of time in diffuse, non-codey ways. There are AAA dependencies you pull into every project, but most other dependencies require a good degree of due diligence, evaluation, risk, and their own long-term maintainance. Its not that it always tips the scales all the way to 'roll your own', but I think the cost of new dependencies is underrated.
- greyhair 6y ago
  But that analysis is part of the design process on the front end. You don't just 'take' libraries or utilities without evaluating them. And you don't just write bespoke libraries without thinking about the APIs. So do your upfront work, by all means. It isn't an all or nothing decision.
VHRanger 6y ago
Found the NPM user. Dependencies have costs: - Dependencies break over time. They have a nonzero maintenance cost. - They impose API boundaries on you that may not fit your existing data structures - It's harder to change underlying bugs - They might introduce security issues Sure, use dependencies. But there's a reasonable position between "never write any code" and "never take on dependencies". Of which NPM is one of the only ecosystems being at one extreme.
- andrewstuart 6y ago
  >> Found the NPM user. Ya got me ... pypi, crates, NPM, gems, cpan I'll use em all! Shhhh.... if my employer finds out they'll fire me. :-)
- scarface74 6y ago
  I could say all of the same things about the in house tools that the “architect” wrote three jobs ago - including the bespoke ORM, object mapper, and logging framework. Or two jobs ago where two developers who had worked at the company for 10 and 15 years respectively were maintaining a bespoke 15 year old EHR written in PowerBuilder and depended on SQL Server 2003 - in 2016. Every company thinks they are their own special snowflake where cross cutting concerns can’t be handled by a third party.
  - JackFr 6y ago
    I’ve worked with dozens of guys who loved to reinvent config and logging frameworks, because ... I don’t know why. I suppose because it was easier than working in the actual problem domain, which they knew little about and didn’t care to learn.
    - nothal 6y ago
      Herding devs to work on the boring-useful things instead of the interesting-solved things is slightly easier than herding cats.
  - karmakaze 6y ago
nomel 6y ago
> "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 estimates will always be wrong. If I understand the actual scope of the problem, which means have the architecture mostly worked out, and have a bit of experience (and luck), my estimates can be pretty close, usually eaten up by that oh-so-seductive feature creep that ruins my work file balance.
- OJFord 6y ago
  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.
  - tome 6y ago
    > the (free online) 'book' on Basecamp's 'shape up' methodology FTI: https://basecamp.com/shapeup https://basecamp.com/shapeup
loup-vaillant 6y ago
> you absolutely should use every dependency you can that will save you time. Absolutely. As long as it does save you that time over the foreseeable lifetime of the project. Or you are deliberately incurring a technical debt because of some deadline. On the other hand, saving an afternoon (or even a week), over the next two weeks means very little.
kosievdmerwe 6y ago
Essentially, it'll take you an afternoon to write and then weeks of work properly fixing the bugs and handling the edge cases. Potentially and probably, while you're trying to do something else.

vlovich123 6y ago

Depends how your dependency management system works. Some times it can take an afternoon or more just to integrate it into your build for c/c++

avmich 6y ago
Somehow here we assume a good programmer routinely makes errors in time estimation by an order of magnitude, yet conveniently forget cases when, say, a non-trivial GPL library is embedded as a dependency into a project, and customer is asking for code, and legal team runs with hairs on fire because company didn't plan to release the code...
- greyhair 6y ago
  But that is a completely different topic. Licensing is an issue, yes, but that is part of the upfront decision process. In this day an age, this many years into open source licensing, if your team is not on top of that from day one, they have failed as a team. I worked at Bell Labs from the mid 1980s to 2000, and by early 1990s (1992? 1993?) they already had a full internal team dedicated to open source licensing issues, including training and consulting. That was 27 or 28 years ago. Before some of the developers on this thread were even born.

scrozart 6y ago

Exactly. I'm not reinventing the wheel. I may write some convenience wrapping around Spring Security, for instance, but why would I rewrite auth-z when it's a solved problem?

avmich 6y ago

> you absolutely should use every dependency you can that will save you time > Find a dependency that will save you an afternoon? Grab it. Agree. The point of the article, though, is that dependencies are often saving much less time than they promise - so much less that it's better to avoid them.

ori_b 6y ago

And when you run into a bug or design problem in a dependency of a dependency of a dependency? It often takes less time to write some code than to understand someone else's code. Most programmers I've worked with get lost easily when jumping through layers of other people's code. I certainly do. Solid, well tested dependencies that solve hard problems are worthwhile. But dependencies have a cost in debuggability and maintenance, so it's worth using them with care. And often, they aren't worth the time, when compared to writing a dozen lines of code.

eberkund 6y ago
I get easily lost jumping through layers of code written by corporate developers in an afternoon. I generally don't have problems jumping through layers of popular, well documented and single-purpose third-party libraries.
quest88 6y ago
Cross that bridge when you get there.

kjeetgill 6y ago

While I agree that if you think it'll just take an afternoon, for the sake of this article it had better! But conceding that charitable assumption to the article, I agree with its basic premise: dependencies cost a lot of time in diffuse, non-codey ways. There are AAA dependencies you pull into every project, but most other dependencies require a good degree of due diligence, evaluation, risk, and their own long-term maintainance. Its not that it always tips the scales all the way to 'roll your own', but I think the cost of new dependencies is underrated.

greyhair 6y ago
But that analysis is part of the design process on the front end. You don't just 'take' libraries or utilities without evaluating them. And you don't just write bespoke libraries without thinking about the APIs. So do your upfront work, by all means. It isn't an all or nothing decision.

VHRanger 6y ago

Found the NPM user. Dependencies have costs: - Dependencies break over time. They have a nonzero maintenance cost. - They impose API boundaries on you that may not fit your existing data structures - It's harder to change underlying bugs - They might introduce security issues Sure, use dependencies. But there's a reasonable position between "never write any code" and "never take on dependencies". Of which NPM is one of the only ecosystems being at one extreme.

andrewstuart 6y ago
>> Found the NPM user. Ya got me ... pypi, crates, NPM, gems, cpan I'll use em all! Shhhh.... if my employer finds out they'll fire me. :-)
scarface74 6y ago
I could say all of the same things about the in house tools that the “architect” wrote three jobs ago - including the bespoke ORM, object mapper, and logging framework. Or two jobs ago where two developers who had worked at the company for 10 and 15 years respectively were maintaining a bespoke 15 year old EHR written in PowerBuilder and depended on SQL Server 2003 - in 2016. Every company thinks they are their own special snowflake where cross cutting concerns can’t be handled by a third party.
- JackFr 6y ago
  I’ve worked with dozens of guys who loved to reinvent config and logging frameworks, because ... I don’t know why. I suppose because it was easier than working in the actual problem domain, which they knew little about and didn’t care to learn.
  - nothal 6y ago
    Herding devs to work on the boring-useful things instead of the interesting-solved things is slightly easier than herding cats.
- karmakaze 6y ago

nomel 6y ago

> "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 estimates will always be wrong. If I understand the actual scope of the problem, which means have the architecture mostly worked out, and have a bit of experience (and luck), my estimates can be pretty close, usually eaten up by that oh-so-seductive feature creep that ruins my work file balance.

OJFord 6y ago
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.
- tome 6y ago
  > the (free online) 'book' on Basecamp's 'shape up' methodology FTI: https://basecamp.com/shapeup https://basecamp.com/shapeup

loup-vaillant 6y ago

> you absolutely should use every dependency you can that will save you time. Absolutely. As long as it does save you that time over the foreseeable lifetime of the project. Or you are deliberately incurring a technical debt because of some deadline. On the other hand, saving an afternoon (or even a week), over the next two weeks means very little.

kosievdmerwe 6y ago

Essentially, it'll take you an afternoon to write and then weeks of work properly fixing the bugs and handling the edge cases. Potentially and probably, while you're trying to do something else.