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.

The first challenge – build a web site that can handle the load.

I got a really creepy piece of mail today. What looks like a newspaper clipping arrives in a white envelope, my address hand written with a blue ball point pen. There is no return address on the envelope and is postmarked with a Research Triangle Region post office stamp. The newspaper clipping has a hand written Post-It note attached to it. The notes says ‘Sai, you gotta see this, J’

The Post-It note is on top of an article about someone who helps folks with sub-prime mortgages.

Frantic google searching followed. It appears that this is the latest method for delivering spam. Found blog posts that talk about this scam, like this one here.

Time sure flies fast, my blog is now a year old. It has been an interesting experience. Blogging can be easy one day and really hard on another day. I am still not sure what I should or shouldn’t blog about. Take today for instance, I can either blog about how to get the Eclipse plugin for vi to work properly in Flex Builder or profound truths about how not to do things. Given a crowded blogosphere, chockful of opinions, some days I feel like I probably should not even bother writing a blog. On the other hand, blogging is pretty therapeutic, just getting my opinions out of the system helps me.

One thing that I can blog about is a transition, I no longer work for IBM. It was a tough decision, I worked there for 8 years with lots of great folks. I will be working for a startup on some exciting new stuff. It was an opportunity I could not pass up. Let us see how this experiment works out.