In any large deployment sooner or later someone is bound to ask, "why change something that works?".
Sometimes things are a lot simpler than they are assumed to be. In the immortal words of the Joker when asked his proposed solution to a seemingly complex problem, he said: "It's simple. Kill the Batman".
The answer to "why change something that works" is "because you fucking have to!"
At least if you're talking about large scale deployment of software.
The fundamental issue here is that software changes, evolves and doesn't stay static.
The statement "works" is very much relative. You claim it works today within acceptable tolerance, that's all well and dandy. How about tomorrow? Surely the definition of "works" depends on the details and what someone requires of a system changes over time as needs change.
"But my requirements are quite specific and I don't intend to change them!" I hear you saying. The fun part comes from the fact that you're not fully in control of the definition of a working system.
Sometimes things are a lot simpler than they are assumed to be. In the immortal words of the Joker when asked his proposed solution to a seemingly complex problem, he said: "It's simple. Kill the Batman".
The answer to "why change something that works" is "because you fucking have to!"
At least if you're talking about large scale deployment of software.
The fundamental issue here is that software changes, evolves and doesn't stay static.
The statement "works" is very much relative. You claim it works today within acceptable tolerance, that's all well and dandy. How about tomorrow? Surely the definition of "works" depends on the details and what someone requires of a system changes over time as needs change.
"But my requirements are quite specific and I don't intend to change them!" I hear you saying. The fun part comes from the fact that you're not fully in control of the definition of a working system.
Continue reading Why change something that works?.
