As soon as I posted about reuse, a old colleague of mine did want to reuse a small piece of code developed by me quite a long while back.
It was nothing great. When we were attempting to make client server connection to CICS in good old days, we were hitting the limits on CICS COMMAREA. We thought if we compress our message, we would not hit the limit. Since it was over-the-wire message all content was required to be non-binary. So one place where we thought we can save space was if we packed integers into higher base representation, because those messages had a lot of integers. So a base 64 representation of integers would take 6 digits as against 9 in a base 10 representation, and still would be capable of going over wire. This piece of code was required to be as optimal as possible. So we had developed a function which would pack integers into base 64 representation. And we had used a trick to make it faster, by taking advantage of EBCDIC representation. It is part of the library we supply along with our MDA toolset.
My colleague wanted to reuse the code, albeit in a different scenario, as it was well tested and is in production for so many years. Needless to say he would have fallen flat on his face, if had blind faith in the code. It would have failed because it relied on EBCDIC representation and he was trying to deploy it in a non-EBCDIC setting.
Why am I narrating this story? It just remphasises my point about implementation reuse. Well, even with best of intentions and support, implmentation reuse is not as easy as it looks. My colleague was lucky to have me around. Who would think such 50 lines of code can go so horribly wrong in a different execution context. If we had seperated the concept from implementation in this case, and generated an implementation for my colleague's execution context it might have worked. But without that he has to do refactoring of code. Which may wipe out gains he may have received by reusing. I am not sure how I could have made that piece of code more reusable than what it is, without breaking non-functional constraint imposed on it by its own execution context.
Now with refactoring we could have a piece code which is more reusable than what it was, but my colleague would have to spend that effort to make it so. It depends whether he has that kind of investment available to him. And it still wont guarantee that it wont fail somebody else's requirement in a totally different execution context. It is making me more convinced that either have concept reuse Or be prepared for refactoring while reuse. And dont expect 100% reuse.
These are my thoughts about various issues faced by an enterprise architect.
Here you will find thoughts related to enterprise architecture, TOGAF, SOA, BPM, MDA, MDD, Web 2.0 etc.
Subscribe to:
Post Comments (Atom)
Tuesday, November 07, 2006
To reuse or not to reuse?
As soon as I posted about reuse, a old colleague of mine did want to reuse a small piece of code developed by me quite a long while back.
It was nothing great. When we were attempting to make client server connection to CICS in good old days, we were hitting the limits on CICS COMMAREA. We thought if we compress our message, we would not hit the limit. Since it was over-the-wire message all content was required to be non-binary. So one place where we thought we can save space was if we packed integers into higher base representation, because those messages had a lot of integers. So a base 64 representation of integers would take 6 digits as against 9 in a base 10 representation, and still would be capable of going over wire. This piece of code was required to be as optimal as possible. So we had developed a function which would pack integers into base 64 representation. And we had used a trick to make it faster, by taking advantage of EBCDIC representation. It is part of the library we supply along with our MDA toolset.
My colleague wanted to reuse the code, albeit in a different scenario, as it was well tested and is in production for so many years. Needless to say he would have fallen flat on his face, if had blind faith in the code. It would have failed because it relied on EBCDIC representation and he was trying to deploy it in a non-EBCDIC setting.
Why am I narrating this story? It just remphasises my point about implementation reuse. Well, even with best of intentions and support, implmentation reuse is not as easy as it looks. My colleague was lucky to have me around. Who would think such 50 lines of code can go so horribly wrong in a different execution context. If we had seperated the concept from implementation in this case, and generated an implementation for my colleague's execution context it might have worked. But without that he has to do refactoring of code. Which may wipe out gains he may have received by reusing. I am not sure how I could have made that piece of code more reusable than what it is, without breaking non-functional constraint imposed on it by its own execution context.
Now with refactoring we could have a piece code which is more reusable than what it was, but my colleague would have to spend that effort to make it so. It depends whether he has that kind of investment available to him. And it still wont guarantee that it wont fail somebody else's requirement in a totally different execution context. It is making me more convinced that either have concept reuse Or be prepared for refactoring while reuse. And dont expect 100% reuse.
It was nothing great. When we were attempting to make client server connection to CICS in good old days, we were hitting the limits on CICS COMMAREA. We thought if we compress our message, we would not hit the limit. Since it was over-the-wire message all content was required to be non-binary. So one place where we thought we can save space was if we packed integers into higher base representation, because those messages had a lot of integers. So a base 64 representation of integers would take 6 digits as against 9 in a base 10 representation, and still would be capable of going over wire. This piece of code was required to be as optimal as possible. So we had developed a function which would pack integers into base 64 representation. And we had used a trick to make it faster, by taking advantage of EBCDIC representation. It is part of the library we supply along with our MDA toolset.
My colleague wanted to reuse the code, albeit in a different scenario, as it was well tested and is in production for so many years. Needless to say he would have fallen flat on his face, if had blind faith in the code. It would have failed because it relied on EBCDIC representation and he was trying to deploy it in a non-EBCDIC setting.
Why am I narrating this story? It just remphasises my point about implementation reuse. Well, even with best of intentions and support, implmentation reuse is not as easy as it looks. My colleague was lucky to have me around. Who would think such 50 lines of code can go so horribly wrong in a different execution context. If we had seperated the concept from implementation in this case, and generated an implementation for my colleague's execution context it might have worked. But without that he has to do refactoring of code. Which may wipe out gains he may have received by reusing. I am not sure how I could have made that piece of code more reusable than what it is, without breaking non-functional constraint imposed on it by its own execution context.
Now with refactoring we could have a piece code which is more reusable than what it was, but my colleague would have to spend that effort to make it so. It depends whether he has that kind of investment available to him. And it still wont guarantee that it wont fail somebody else's requirement in a totally different execution context. It is making me more convinced that either have concept reuse Or be prepared for refactoring while reuse. And dont expect 100% reuse.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment