Hacker News Reader

Comment by derFunk | Hacker News Reader

I liked the part about "technical debt". Yet I don't like this statement: "You should aspire to upgrade your dependencies and frameworks all the time". It's too generic.

I'm thinking about third party dependencies here (eg via package managers). In my opinion it's best practice to stick with one certain stable version and then stop updating it - to avoid wasting time on possible needed refactoring due to changed dependency behaviour. Monitoring the change log of the dependencies to see if security issues are fixed and reacting on that is of course still reasonable. Yet upgrading just because " upgrade as often as possible" is not.

Maybe it's different for projects lasting 10years or more, maybe there are other rules to make. My experience is with 2.5yr-projects in average.

Maybe I'm working with dependencies which get updated every week or so, maybe the author's dependencies are updated every half-a-year.

View on HN

If you're not tracking the changes of your dependencies, you're moving that work (finding and fixing the problems) to your future self/team. That might be a win if future you won't need to continue to support/develop the thing. I think it's a loss in other cases. IME, you end up trying to swallow a sea of changes all at once, sometimes triggered by something that you can't control. "Oh, I need to take the new rev of foo; that needs a newer version of bar and baz. Baz needs a new quux..." Suddenly, you've got a lot of fixing and regression to do, and if the need for the new foo comes at a bad time, you may have lost control over your schedule predictability entirely.

Moving an expense from today to the future is debt.

The point about the need to upgrade dependencies as being sometimes forced by events beyond our control is a good one.

Debt (technical or otherwise) in itself is not a bad thing if used sensibly for some gain. Allocating resources to maintain dependencies is not necessarily the best short or long term investment.

These are all heuristics.

Documented technical debt is not a bad thing. If it's undocumented (aka everybody except the "debt creator" is unaware), it's hell.

I absolutely agree if you're planning to have a long living project.

Sure, but you won't need to pay off the debt if you go bankrupt.

I've found in practice the effort to go from a -> b -> c -> d in aggregate is often far less than the effort to go from a -> d.

In addition I've found the stability of the system as a whole is better when you swallow the pie in small chunks and when your project depends on multiple dependencies upgrading them gradually piece at a time makes bisections much simpler than "stop the world and update".

It really does depend (as most things do) on the particular domain/problem/solution though, if I was working on something that ran for years and couldn't be touched in production I'd probably go the other way.

Though I concur that your caveats are valid, I do think dependencies should be upgraded to newest-LTS sooner rather than later. Once the dependency falls out of upstream maintenance, it's a time bomb; and we've found (inhouse stuff for public website consumption) that if you don't do the upgrade to newest-LTS sooner, you never quite get around to it until it blows up in your face. And that's not so good.

We keep finding over and over that the wonderfully-engineered project is thrown away after about three years, but that nothing lingers longer than a temporary hack. So we're getting better at futureproofing our temporary hacks ...

I think it comes down to what kind of product you're building and what kind of libraries you're using. If you're doing some web-facing product that's being continually developed, and there's a security update in a library or framework, then sure.

If you're building a traditional piece of software (no "evergreen" continual updates, maybe even with no upgrade process at all eg. device firmware) then just using a library internally, and your requirements aren't changing, then continually updating it is busywork at best, and a risk to the reliability and stability of your project at worst.

It's not "technical debt" to skip point releases that don't add anything to your project, since you avoid potentially re-integrating changes to the same features if they change multiple times, and there's a good chance you'll never need to update at all.

The article's focus is on avoid brittle code. By updating your dependencies often, you will shake out accidental coupling or assumptions in your code. It might be expensive in the short time, but it will make future upgrades easier. For example, if you are on library version 2.1 you will have a harder time jumping to version 4.3 to get some headline-making security update. You also avoid time spent debugging bugs that may have been fixed in a newer version of one of your dependencies.

That said, updating every week might be unnecessarily frequent. :)

Upgrading everything without cause is one of the worst ideas I've heard in a long time. It leads to a lot of unnecessary work that could likely have been avoided otherwise, not to mention breaking the app itself. And if you end up on a version of a dependency that no longer works or is no longer supported in favor of a new package? What then? Rewrite all my code? What incredibly stupid advice to upgrade everything. The rest of the article is not much better either.

If you are using a web framework, its a good idea to keep it up to date, a many security holes get fixed. And in my experience when doing this with Django, its often necessary to upgrade some of the packages so that they work with the newer version of he framework. Keeping everything (reasonably) up to date as you go is the easiest way to avoid "one big upgrade of everything" - which can be a nightmare as you suggest.

That approach might have worked 20 years ago when a big project had more than 3 3rd-party libraries and CPAN was the pinnacle of dependency management, but it's burying your head in the sand in this day and age. Security patches are a fact of life, and unless you've air-gapped everything, aren't optional. Sooner or later you're bound to run into bug fixes or api improvements that will force your hand as well. Not being proactive about keeping your dependencies up to date is like only eating dessert and never eating vegetables.

Being overly proactive is just as bad. The majority of the bugs haven't been in there since the init commit, they were added over time. Often you are just swapping known bugs for unknown bugs (which is arguably worse) particularly when the update contains more than just a tiny bug fix.

I agree again, it smells like premature optimization which is bad practice (been there).

Fine, you're okay with old bugs. You're pretending that that's the main issue though. What's your excuse for punting on security updates?

Reply on news.ycombinator.com