4 ms·
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
by gbin 2y ago
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.
- hinkley 2y agoWe 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.