In a recent post, I mentioned the acronym OPC, meaning "Other People's Code." Somehow I doubt I'm the first person to use the acronym, so I don't intend to claim it as my own. I can't say I've seen it before, but it seems so obvious that it should be one because OPC is so prevalent and we should all be talking about OPC much more than we do. In an industry that arguably values reuse over every other virtue, you'd think that OPC would have long been canonized.
Yet it seems to me that when most people speak of reuse, they mean Their Own Code (TOC, I love overloading acronyms!) or, from their perspective, My Own Code (MOC). In essence, they want other people to reuse their code, but there ain't no chance in heck that they're going to use OPC as a means to achieve the ultimate goal. I want MOC to be reusable. How can I impress my friends by writing code that can be reused by as many other people as possible? This is something I think most of us that strive to be great at software think at one point or another, perhaps not in so many words, but ultimately, there is a sense of great pride when you polish off that last speck on your chrome-plated masterpiece, showing it to your buddies or the world in general and saying "that's MOC."
The funny thing is that more often than not, the really ardent software folks among us, and even the less ardent, have a predilection for the NIH syndrome. It's because we're all so damned smart, right? Surely, those other folks at NIH Co. couldn't possibly have done it as well as I could have!? Of course, we've got all the rationalizations lined up for when the business folks ask:
1) "I can't support that because I don't know it--I need the source code."2) "You know, it won't meet our needs just right, not like I could do it for you custom."3) "How much? Geez. I could write that in a day!"4) "It's not using X, which you know is our preferred technology now."5) "Did they promise to come work here if they dissolve the company? I mean, you're just gambling on them."
And the list goes on. We've probably all done it; I know I have. Why? Because, as one developer friend once put it (paraphrased): "I love to invent things. Software is an industry where you get to invent stuff all the time." In other words, we're creative, smart people who don't feel that we're adequately getting to express our own unique intelligence unless we write the code ourselves.
And now we finally come to what prompted this post. I recently looked over an article by Joshua Greenberg, Ph.D. on MSDN called "Building a Rule Engine with SQL Server." I'm not going to comment on the quality of the solution offered because I hardly think I am qualified to do so. What I was completely flabbergasted by is the total omission of the rules engine being built into Windows Workflow Foundation. Surely someone who has put that much thought into the theory behind rules engines, which, as is mentioned in his conclusion, are probably best known in workflow systems, would be aware of WF's own? Surely one of the editors at MSDN Mag, which has done numerous articles on WF, including one on the engine itself published in the same month, would think it worth noting and perhaps comparing and contrasting the approaches?
Now, I don't want to draw too much negative attention to the article or Mr. Greenberg. He and the editors are no more guilty of ignoring OPC than most of us are. It is just a prime example of what we see over and over again in our industry. On the one hand, we glorify reuse as the Supreme Good, but then we turn around and when reusable code (a WinFX library, no less!) is staring us in the face, an SEP field envelops reuse, enabling us to conveniently ignore OPC and start down the joyous adventure of reinventing the wheel.
This has got to stop, folks. I'm not saying that this ignorance of OPC is the primary cause of the problems in our industry (I happen to think it is only part of the greater problem of techies not getting the needs of business and being smart enough to hide it). But it is certainly one that rears its ugly head on a regular basis, as we guiltily slap each others' backs in our NIHA (NIH Anonymous) groups. We have a responsibility to those who are paying us and a greater responsibility to the advancement of our industry (and ultimately the human race) to stop reinventing the wheel and start actually reusing OPC. I'm not saying there is never a justification for custom code (God forbid!), but that custom code needs to be code that addresses something that truly cannot be adequately addressed by OPC.
There will always be plenty of interesting problems to solve, which give way to creative and interesting solutions. Just imagine if all this brainpower that goes into re-solving the same problems over and over again were to go into solving new problems. Where would we be now? Now that's an interesting possibility to ponder.
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.
Thanks to the good folks at dasBlog!
Copyright © 2017 J. Ambrose Little