←back to thread

Software Friction

(www.hillelwayne.com)
141 points saikatsg | 2 comments | | HN request time: 0.001s | source
1. gbin ◴[] No.40719664[source]
The example about the software updates resonates with me. My policy is usually for the team, if you can upgrade your dependencies, just upgrade now. I have seen so many companies just taking the short term thinking again and again just to realize that oh, now it is too much of a step to update anything let's... Wait? Friction is way easier to take amortized over a longer time so you have to basically bake that in the everyday processes, oh an update? We are not in a bind, just upgrade! It is related to tech debt basically, just avoid accumulating it because it compounds very badly.
replies(1): >>40719844 #
2. hinkley ◴[] No.40719844[source]
We had a hell of a time getting a fix for a CERT advisory deployed because we were several versions behind and there were breaking changes in the way. The idea of rushing a change to make a system more robust is absurd because all of the rushing is your surface area for regressions.

Our solution was that at least once a month we had a story to upgrade deps. But as each new person got the assignment they would immediately ask the question, “but upgrade what?” I didn’t have enough information at that point to care, so I told them to just pick something. Our dep pool wasn’t that big and any forward progress was reducing the total backlog so I figured they would pick something they cared about, and with enough eyeballs we would collectively care about quite a bit of the project.

Now part of the reason this ranked a story is that we were concerned about supply chain attacks on this project, so it wasn’t just a matter of downloading a new binary and testing the code. You also had to verify the signature of the library and update a document and that was a process that only a couple of us had previously used.