On Software Reuse
Software reuse is one of the most fascinating topics there is. A source of many myths and the basis of many project management blunders. I came across this brilliant article by Peter Naur. The article touches on so many points near and dear to my heart. From the industrial era project management techniques used in software to why teams consisting of smart programmers will frequently produce unusable junk and become miserable in the process. More on those topics in subsequent posts.
Programming as theory building is also a big reason a lot of software is not as reusable. The original programmer’s theory building exercise in the context of the problem domain has to be applicable to the problem you are solving. If you either do not understand that theory or even if you do not agree with that theory, it is far wiser to not reuse the code. The love/hate posts on Ruby On Rails I have seen on the net are a good example of this effect at work. Folks who agree with the original theory find the framework amazingly productive. Folks who either don’t get it or don’t agree with it, find it useless and will refuse to reuse the framework. Personalizing the theory behind Ruby On Rails, modifying it to suit one’s world view has resulted in so many other frameworks being created.
Another fascinating book that touches upon this topic of reuse (albeit in a slightly roundabout fashion) is The User Illusion. The book goes into a deep discussion on the nature of information, a discussion that then supports the author’s theory of the brain. One point that stuck me while reading the book relates to software reuse that Peter brings up in his article. Documentation does not really help in reusing software.
The amount of information that programmers discard before writing a line of code is actually far more important than the line of code that gets written. In fact, the complexity of a program is more a result of the amount of information discarded than the amount of information that gets encoded in the program text. No amount of documentation can make up for the information that is in the programmer’s head when the code was written. Without that information, the code is useless. Unless, you face the exact same problem and the code maps well into your context.
The exceptions are the gems, libraries that help you without imposing their theory on your code. Ironically, artifacts like EJBs which were built with reuse in mind, failed miserably at that task. The theory behind EJBs met with violent disagreement, theory building is fine, imposing that theory on everyone is and always will be risky business.
The next time you are wondering why that other programmer’s code looks like crap, it could be because the code is truly crap or maybe you just do not understand the underlying theory of the program or maybe you sub-consciously do not agree with it. It might be that the original programmer discarded way too much information that is relevant to you or you have clue no why they discarded the information. In all these cases, the best course of action is to just re-write the code. Now, if you find yourself wanting to re-write something as complex as Windows, reusing Mac OS X or Linux might be easier.
8. April 2008 at 23:14
I do agree that discarding information is at the core of what makes an asset reusable or not. That said you could consider that the information that was discarded was of little value to the author and could be of as little value to you given the same problem context. When the problem context changes, the value of the information surrounding that context changes too. This raises a dilemma in that it is very likely that the pace of change in the 21st century could preclude reuse except at the most granular level or at the most abstract level.