Managing Code Reuse

Reusing code seems to be one of the most difficult task in the current development environment. Management wants it but there is a lack of effort to structure the development process to achieve this. Developers are creative by nature and resist the requirement to reuse code from someone else. The arguments are consistent in that other developers don’t write clean code or the interface is too difficult to understand. It is always easier to write it from scratch.

Recently there have been two instances of developers taking the time to write a date routine instead of using standard libraries. While this probably happens more often than I care to imagine, these two incidents were discovered in testing. It seems not all developers know that noon is really 12:00 PM instead of AM. This is a perfect example of the danger of not reusing code and allowing the development staff to work without control.

Enter “The LIBRARIAN”

Implementing the practice of Librarian today would be much more efficient as there are already systems to manage the use of and approval for open source software. If these principles were applied to code today, software would be more robust, take less time to develop, have a more consistent look and feel and reduce cost of development.

Long ago in a land far away there were mainframe coders. They were the first generation of geeks and compute time was sold to business for $300 per minute. To put this in perspective, at that time a new car cost $3,000 so a 10-minute runtime mistake could be disastrous. It was imperative that code was reused as often as possible and new functions were only added to a system if no other library or routine was written to do the same thing. Coders were not free to do whatever they wanted and they couldn’t copy code from a website that looked cool.

There was a set of books about six feet wide organized by function then alphabetically. As a programmer, you were expected to find code to complete what you needed to do. Each function had input interfaces and output interface and a description of what the function did. If you couldn’t find what you were looking for, you created a document with input and output interfaces and a description of what it would do and a list of similar functions that were defined in the books. With that document, complete, you took it to the Librarian.

The Librarian was typically a seasoned developer who was burned out from the pressure of perfection (at the time you could buy a new car for $3K so there was a lot of pressure). The company did not want to lose that talent so they became the Librarian until such time as they could resume their position. These guys knew everything.

Usually when a document was handed to the librarian, he would spend a few minutes reading it and then refer the author to a book and specific function that did exactly what was needed. On the occasion where this really was a unique function / process, the Librarian would then determine if you were going to write a new function or modify the existing function to complete what was needed. Modification always had to be immutable, not destroying the interface used by previous efforts.

 At the time this did not seem to be an onerous process and it reduced the risk of failing code or silly bugs that delayed time to market or caused problems for customers using the software.

Copyright 2019 David Cosby