Comment by Silhouette | Hacker News Reader

Comment by Silhouette | Hacker News Reader

Parent Full thread

One danger is that dependencies are not getting updated regularly and one day one find oneself depending on a very old version of a dependency.

That is only a problem if the old dependency no longer provides the required functionality, though. In many cases, that will never happen.

The other is that it may not always be possible/practical for other people to be at the that exact version. Some libraries can depend on system libraries that cannot be easily upgraded. E.g., numpy depends on underlying system libraries and it is not always possible to choose whatever version. GUI-libraries ultimateley depend on system GUI-libraries which also, practically speaking, cannot be updated to any random version.

Ironically, the problem you've described here originates with dependencies not having stable dependencies themselves. This is why it's so important for foundations like operating system or other platform APIs to offer excellent stability and longevity, and more generally for libraries that want to be relied upon to offer clear version information and backward-compatible updates.

One question that one can ask, though, is whether one wants to experience that pain sooner or later. I am thinking of https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... here.

But what if you never have to experience that pain at all? Or if you can experience it only once, much later, when it really does become unavoidable, instead of experiencing a similar amount of pain multiple times along the way?

Look at the sketch graph in that article, the one with time between actions and pain as the axes. Tell me what it means.

Nothing. It means nothing. It conveys literally no evidence or data of any kind. And the entire argument rests on that non-existent foundation.

Just one data point, but doesn't Google advocate for living at head? Long-lived software can't be static.

Yes, and keeping up with these changes is a treadmill, for developers.

They also statically link binaries, though, and an old binary could be in production for a while if the product isn’t being worked on.

The popularity of Docker files shows another way of freezing dependencies.

The general principle here is that changes get tested during the release process. You’re not creating new combinations of dependencies and running them in production without testing.

(Well, within the same binary, at least. Servers talking to each other over the network may be unexpected combinations.)

But why should we take Google seriously as an example of good software development practice? For an organisation with effectively unlimited dev resources, it breaks things pretty often and kills off a lot of products outside of the star performers that support everything else. And thanks to the dominance of Chrome and Android, when Google does break things, the pain is shared by countless other developers as well. No-one can deny that Google has been a wildly successful business, but whether its current software development practices have anything to do with that or make it a worthy role model to emulate is a different matter.

Yes, take their lessons with a grain of salt, but they have a ton of experience, and shouldn't be dismissed out of hand either.

> Nothing. It means nothing.

It means that as time passes by, the things that need to be done accumulate and hence the pain of doing them. You don't need evidence for that. Its a common sense.

Otherwise, give one example when waiting for action (and in absence of divine/external intervention) makes it easier. Via this logic we can deduce that there must exist 100% self-fixing entities. I am not aware of any such thing. Many entities have some autocorrection (including us) but up to a certain point and usually (only?) when life is involved.

It means that as time passes by, the things that need to be done accumulate and hence the pain of doing them. You don't need evidence for that. Its a common sense.

I couldn't disagree more. It is not self-evident either that updates will inevitably need to be done or that the pain of doing them if they are needed will increase (never mind increase exponentially, as the article arbitrarily claimed) with time.

You should introduce an external dependency into your program if and only if it provides useful extra functionality and the benefits of using it outweigh the costs. You should update an existing dependency to a new version under exactly the same conditions.

Otherwise, give one example when waiting for action (and in absence of divine/external intervention) makes it easier.

When you never need to take that action at all, for example if you include a library in your program and the library does what you need and that's that.

> It is not self-evident

OK, how about this: any work done has non 0 probability for mistake (now we can use math to deduce the same)

> You should introduce an external dependency into your program if and only if it provides useful extra functionality and the benefits of using it outweigh the costs. You should update an existing dependency to a new version under exactly the same conditions.

People are bad in judging such stuff hence this is tautology and provide no actionable advice.

> When you never need to take that action at all, for example if you include a library in your program and the library does what you need and that's that.

This doesn't qualify as you already said that "you dont need to take action". I said "when waiting for action" which implies action must be done at some point.

Reply on news.ycombinator.com