6 ms·

Backstage is great at slowly migrating dysfunctional organizations into slightly less dysfunctional organizations. I deal with 30 years of random tech debt in a

by _cenw 2y ago

Backstage is great at slowly migrating dysfunctional organizations into slightly less dysfunctional organizations. I deal with 30 years of random tech debt in a company with immense shadow IT (domains randomly registered, vendors randomly hired to do X, often nobody knows things are still needed, our zonefiles are a mess, unclear responsibilities with our team of 4 being the default fallback), and Backstage at least puts some semblance of insight into that entire mess and provides a way forward to formalize such processes. Also, putting documentation where developers commit to every day instead of a Wiki where it's out of sight / out of mind is very underrated.

parpfish 2y ago
But doesn’t that mean you have a long migration period with two systems to maintain and reconcile?
- eszed 2y ago
  Yes. I've seen this go well, and I've seen this go terribly. It works (in my experience) when the migration work is pushed down to the directly responsible teams - with, of course, affordance made for the time it will take them. (Sidenote: that has the benefit that they learn / re-learn their dependencies for themselves, and discover efficiencies they never would have otherwise.) An overarching "migration team", or whatever you choose to call it, only adds friction, confusion, and more kludges. Management has to be fully committed, and enforce deadlines all the way down the line. Running two systems can (usually) be done short-term, but not long. (Another thought: "short" and "long" terms are variable for different teams and different types of services. Scheduling should take that into account.) Admittedly, however, I've not been through it at a particularly large organization. I'm sure there is exponentially metastasizing complexity (human perhaps even more than technical) once the process involves more people than can fit in a room.
- p_l 2y ago
  In such dysfunctional case the truth is that you do not have an old system to reconcile with - there's no real system of record

by _cenw 2y ago

parpfish 2y ago

But doesn’t that mean you have a long migration period with two systems to maintain and reconcile?

eszed 2y ago
Yes. I've seen this go well, and I've seen this go terribly. It works (in my experience) when the migration work is pushed down to the directly responsible teams - with, of course, affordance made for the time it will take them. (Sidenote: that has the benefit that they learn / re-learn their dependencies for themselves, and discover efficiencies they never would have otherwise.) An overarching "migration team", or whatever you choose to call it, only adds friction, confusion, and more kludges. Management has to be fully committed, and enforce deadlines all the way down the line. Running two systems can (usually) be done short-term, but not long. (Another thought: "short" and "long" terms are variable for different teams and different types of services. Scheduling should take that into account.) Admittedly, however, I've not been through it at a particularly large organization. I'm sure there is exponentially metastasizing complexity (human perhaps even more than technical) once the process involves more people than can fit in a room.
p_l 2y ago
In such dysfunctional case the truth is that you do not have an old system to reconcile with - there's no real system of record