Most software is a composition of layers of fossilised snapshots of the organizational understanding of the problem those layers were originally designed to solve - but we rely on it as if it is continually maintained critical infrastructure.
One of those has to give.
One of those has to give.
What a system was designed to do, what it does, what it is supposed to do, and what people use it for are 4 mostly unrelated concepts.
Asbestos problems, where you've introduced a dependency to serve purpose but due to "unforeseen" danger now needs to be completely replaced, suck - but competent organizations have continuous deployment pipelines and dependency tracing . At worst, at least you know of the danger.
The problem is most organizations don't consider software a competency - at best they consider it a cost center, and at worst they consider it an asset class.
"Out of all possible dependencies predict the next Asbestos" is an intractable problem.
"How to quickly remove Asbestos from a system" is a solved problem and has a clear investment path.
Which doesn't bode well.
"How to quickly remove Asbestos from a system" is a solved problem and has a clear investment path.
Which doesn't bode well.
It is cheaper to build reactive capabilities while investing in the problems you care about.
It is expensive to divert that funding towards critical infrastructure to prevent the need to react in the first place.
And round and round we go.
It is expensive to divert that funding towards critical infrastructure to prevent the need to react in the first place.
And round and round we go.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
