Advertisment

Coder, heal thyself

author-image
PCQ Bureau
New Update

Krishna

Kumar
Advertisment

Object oriented is a phrase that is etched into a modern-day coder's psyche. While there are many, many advantages of using the object-oriented way of writing code, one of the underlying benefits is the ability to reuse code.

Let me explain this with a simple example. I end up making three or four presentations every month, to various audiences. If you are wondering, I use both PowerPoint and Openoffice.org Impress, and, occasionally for effect, I run a presentation off a browser also. But that is besides the topic. I have saved copies of presentations I have made over the years. Now a days, I can get a basic presentation on any of my regular topics up and ready in less than thirty minutes. I pull in slides from previous presentations into a new file and make minor changes in them to achieve this. There is nothing great in what I do.

Code reuse is a bit like this. Functionality you have written once can be reused with maybe minor tweaks in future projects, saving on time and effort. Building code components avoids even the minor tweaks. More importantly, the developer does not have to reinvent the wheel again and again.

Advertisment

Code reuse is slightly more complex than slide reuse. For starters, the code has to be properly documented-commented at the bare minimum-so that later-day coders know what that particular bit of code is supposed to do, and what it is supposed to take as input. Then, there should be no hard-coded values or references. And finally, you need a good system to store, catalogue and retrieve the code.

It is not that we do not know this. But how many of us, how many of our world-class software shops, implement this? If the examples that I have seen and heard of are anything to go by, then not too many. Not all the big ones. Not all the better ones.

Definitely, not all the smaller ones.

The reasons given for not doing this are many-the rush of projects, the lack of good documentation experts, the unwillingness of management to focus on and spend on backend systems and processes....

It is easy to claim that we are software creators to the world, and I am not disputing that at all. But the question is: are we treating our coders as code monkeys or as intelligent human beings? Are we handling problems intelligently, or are we simply throwing more and more manpower at them in the hope that, as Vinod Unny often points out, enough monkeys on typewriters will somehow create a Shakespearean classic? ¨

Advertisment