5 ms·

I have a simple proposal why SE’s are externally strapped for time: upgrades. No not security patches. Upgrades. Like ‘oh the newest best version of React was

I have a simple proposal why SE’s are externally strapped for time: upgrades. No not security patches. Upgrades. Like ‘oh the newest best version of React was released yesterday and I’ve just GOT to have those and management doesn’t understand how productive I’ll be and they shorted us on our last upgrade by not letting us go all in’ This endless treadmill of half baked framework features and ui refreshes streaming in the root problem. I really think a team that can close the gate and seal the seams from the problem would be the most effective. That would mean your most important KPIs would be something like: * number of new features imported from frameworks (close to zero is ideal). These are expensive, like millions of dollars each. * number of security patches applied/response time/etc (maximize these) * eliminate things with no or short LTS, measure weighted lts: (LOC using framework multiplied by framework LTS) Now this in and out itself isn’t sufficient to measure an organization’s productivity, but these would would keep it on the straight and narrow so other measures would become effective.

mjr00 3y ago
This is far too narrow of a scope to be broadly applicable. The industry in general does not spend nearly as much time upgrading packages as you imply, and your metrics don't make sense either. How do you measure the number of "features" imported from a framework?
simonw 3y ago
I'm with Charity Majors on this one: https://twitter.com/mipsytipsy/status/1778534529298489428 https://twitter.com/mipsytipsy/status/1778534529298489428 "Migrations are not something you can do rarely, or put off, or avoid; not if you are a growing company. Migrations are an ordinary fact of life. Doing them swiftly, efficiently, and -- most of all -- completely is one of the most critical skills you can develop as a team." See also this, one of my favourite essays on software engineering: https://lethain.com/migrations/ https://lethain.com/migrations/
- Aqueous 3y ago
  "Doing them swiftly, efficiently, and -- most of all -- completely is one of the most critical skills you can develop as a team." That all sounds great. However, I'd like to understand what teams are actually able to do this, because it seems like a complete fantasy. Nobody I've seen is doing migrations swiftly and efficiently. They are giant time-sucks for every company I've ever worked for and any company anyone I know has ever worked for.
  - simonw 3y ago
    That's why it's celebrated as a valuable skill - it's hard! Did you read this? https://lethain.com/migrations/ https://lethain.com/migrations/ I have decades of experience and I'm just about reaching the point now where a migration like this doesn't intimidate me.
    - Aqueous 3y ago
      The fact that it takes decades to master such a mundane task may mean the entire approach is wrong. The article hand-waves a lot of the complexity of "automating as much as possible." In my opinion, the solution lies in append-only software as dependencies. Append-only means you never break an existing contract in a new version. If you need to do a traditional "breaking change" you instead add a new API, but ship all old APIs with the software. In other words - enable teams to upgrade to the latest of anything without risking breaking anything and then updating their API contracts as necessary. This creates the least friction. Of course, it's a long way for every dependency and every transitive dependency to adopt such a model.

mjr00 3y ago

This is far too narrow of a scope to be broadly applicable. The industry in general does not spend nearly as much time upgrading packages as you imply, and your metrics don't make sense either. How do you measure the number of "features" imported from a framework?

simonw 3y ago

I'm with Charity Majors on this one: https://twitter.com/mipsytipsy/status/1778534529298489428 https://twitter.com/mipsytipsy/status/1778534529298489428 "Migrations are not something you can do rarely, or put off, or avoid; not if you are a growing company. Migrations are an ordinary fact of life. Doing them swiftly, efficiently, and -- most of all -- completely is one of the most critical skills you can develop as a team." See also this, one of my favourite essays on software engineering: https://lethain.com/migrations/ https://lethain.com/migrations/

Aqueous 3y ago
"Doing them swiftly, efficiently, and -- most of all -- completely is one of the most critical skills you can develop as a team." That all sounds great. However, I'd like to understand what teams are actually able to do this, because it seems like a complete fantasy. Nobody I've seen is doing migrations swiftly and efficiently. They are giant time-sucks for every company I've ever worked for and any company anyone I know has ever worked for.
- simonw 3y ago
  That's why it's celebrated as a valuable skill - it's hard! Did you read this? https://lethain.com/migrations/ https://lethain.com/migrations/ I have decades of experience and I'm just about reaching the point now where a migration like this doesn't intimidate me.
  - Aqueous 3y ago
    The fact that it takes decades to master such a mundane task may mean the entire approach is wrong. The article hand-waves a lot of the complexity of "automating as much as possible." In my opinion, the solution lies in append-only software as dependencies. Append-only means you never break an existing contract in a new version. If you need to do a traditional "breaking change" you instead add a new API, but ship all old APIs with the software. In other words - enable teams to upgrade to the latest of anything without risking breaking anything and then updating their API contracts as necessary. This creates the least friction. Of course, it's a long way for every dependency and every transitive dependency to adopt such a model.