In a production environment, code re-use is often quoted as a time saver, a safety net in the case of tight deadlines, and an extra piece of assurance for the bullet point on your viewfoil that states your confidence level in meeting the project milestone of record. By code re-use I don’t mean buying code from other companies, through outright purchase, licensing, or on a SDK basis, but the simple act of making most functionality in your program re-useable across your own product group. This will mean the following:
* abstracting the data types
* abstracting the behavior so it makes sense for the additional data types
* abstracting the return types
and, the often overlooked
* publicizing this work so that people know that you’ve done it.
The trick here for a Program Manager is that code re-use is a double edge sword. It may be the case that the existing code available for re-use has not gone through the work of abstraction, however good it may be. It may also be the case that the existing code has been abstracted just fine but it wasn’t any good in the first place. There is as much to lose as there is to gain. No wonder that programmers tend to write their own code for everything. Only with the most formidable task in front of them will they look through emails or check-in logs and determine if there’s anything to re-use. That way, if their code breaks or succeeds, they know they can fix it discretely, and without uncovering a nest of snakes. If this “extra code” takes more time, well, it is commonly the only way they’ve ever worked, so this time was padded into their estimate anyway.
As an incoming Program Manager to a project, it is essential to do a reality check on this aspect of the code for yourself. Don’t take the dev lead’s word for it. This means getting a build version of the code on your machine, along with your promises not to check anything in. Then take a look. Run some searches on function calls. How much code is really being shared?
If lots of code is being shared, then the question is how successfully. Determine metrics based on your bug database how many times a particular routine was repaired. Some routines will not have needed repair at all, other routines lots. Does the project do code reviews or development by pairs? If this is the first rev they have done so, consider implementing a policy of sharing only code from this version and later, the code will be of such higher quality.
Overall code re-use cannot be a simple yes or no. It cannot be faked or used as a confidence booster to the schedule, like unscheduled overtime or weekends. It needs to be considered among the rest of the factors at play. This may be a good time to fess up and throw out the policy, if it will improve code quality. Next rev, you can base changes on existing quality code rather than shoring up a sinking ship.
5:31:43 PM 
|
