Many problems that businesses have with software seem to involve visibility. The role that specific software components play within an organization are often hidden, obscured, or just plain forgotten.
I have been in shops where software has been reliably clunking along for 20 years... faithfully executing night after night, 7 days a week, 52 weeks a year... for decades. Undoubtably, this software "keeps on ticking" because it is doing something useful for the business... but I also suspect that some of the things that the software is doing may no longer be necessary. In many IT shops there is a distinct "If it ain't broke don't fix it" mentality, and if you aren't sure you just leave things as they are.
My friend Si told me a story about an accounting package that was written many years ago (in the early 1960's) for a machine that has long since become extinct. Rather than rewrite the package when the company upgraded their hardware to the next generation, an emulator for the original hardware was obtained . Years later, when the company upgraded their hardware once again, they continued to run the package, on an emulator for the 2nd generation hardware that ran an emulator for the original hardware.
Si swears that this is a true story... and given the conservatism of a lot of organizations I have no reason to doubt him.
This anecdote relates an extreme case, but I doubt that it is unique. We keep doing things not just because we've always done them, but because we can't always "see" what's really going on. In general, we know what a package does, but we can't see its side effects and interactions with other software package. "Something else" may rely on our package, and there is no real way to know what will happen except to shut down our package and wait to see what happens. That's a scary proposition in a production environment.
Going back to Si's anecdote, continuing to use the legacy accounting package could be held up as a poster-child for software reuse. Did it really matter that the implementation details of the package were unknown as long as the package continued to perform as advertised?
Sound object-oriented engineering principles encourage "hiding things". Hiding implementation details behind published interfaces is essential when building any non-trivial system... When building the system, you really don't need to know how a function is implemented, you just want it to work as advertised... and apparently Si's accounting package did just that.
But my gut tells me that something's not quite right. We don't decouple implementation from interface solely for the benefit of those who consume our software... Interfaces are meant to benefit both parties. Our consumers don't have to worry if the implementation changes, and we don't have to worry about changing the implementation.
In Si's anecdote, the accounting package survived due to fear. Nobody understood the original code, so everybody was afraid to touch it. In a real sense the implementation was hidden (since it was written in an extinct assembly language).
I think we've got a visibility paradox. We need to hide implementation details behind interfaces, but at other times we need to know those very same implementation details.
Our challenge is to have it both ways. An application should never rely on the implementation details of its components... but we must be able to delve into those implementation details when necessary. When we need to upgrade hardware or operating systems, or when we need to diagnose and resolve performance issues, we need to know the details... or we may be forced into bizarre solutions like the one Si relates.
I have been in shops where software has been reliably clunking along for 20 years... faithfully executing night after night, 7 days a week, 52 weeks a year... for decades. Undoubtably, this software "keeps on ticking" because it is doing something useful for the business... but I also suspect that some of the things that the software is doing may no longer be necessary. In many IT shops there is a distinct "If it ain't broke don't fix it" mentality, and if you aren't sure you just leave things as they are.
My friend Si told me a story about an accounting package that was written many years ago (in the early 1960's) for a machine that has long since become extinct. Rather than rewrite the package when the company upgraded their hardware to the next generation, an emulator for the original hardware was obtained . Years later, when the company upgraded their hardware once again, they continued to run the package, on an emulator for the 2nd generation hardware that ran an emulator for the original hardware.
Si swears that this is a true story... and given the conservatism of a lot of organizations I have no reason to doubt him.
This anecdote relates an extreme case, but I doubt that it is unique. We keep doing things not just because we've always done them, but because we can't always "see" what's really going on. In general, we know what a package does, but we can't see its side effects and interactions with other software package. "Something else" may rely on our package, and there is no real way to know what will happen except to shut down our package and wait to see what happens. That's a scary proposition in a production environment.
Going back to Si's anecdote, continuing to use the legacy accounting package could be held up as a poster-child for software reuse. Did it really matter that the implementation details of the package were unknown as long as the package continued to perform as advertised?
Sound object-oriented engineering principles encourage "hiding things". Hiding implementation details behind published interfaces is essential when building any non-trivial system... When building the system, you really don't need to know how a function is implemented, you just want it to work as advertised... and apparently Si's accounting package did just that.
But my gut tells me that something's not quite right. We don't decouple implementation from interface solely for the benefit of those who consume our software... Interfaces are meant to benefit both parties. Our consumers don't have to worry if the implementation changes, and we don't have to worry about changing the implementation.
In Si's anecdote, the accounting package survived due to fear. Nobody understood the original code, so everybody was afraid to touch it. In a real sense the implementation was hidden (since it was written in an extinct assembly language).
I think we've got a visibility paradox. We need to hide implementation details behind interfaces, but at other times we need to know those very same implementation details.
Our challenge is to have it both ways. An application should never rely on the implementation details of its components... but we must be able to delve into those implementation details when necessary. When we need to upgrade hardware or operating systems, or when we need to diagnose and resolve performance issues, we need to know the details... or we may be forced into bizarre solutions like the one Si relates.
No comments:
Post a Comment