Libraries or Code Generators?
Every software development company comes across repetitive coding problems. It can be something as simple as a bank account check-digit or a number writing routine. It can also be something more complex, like reusing a database access architecture.
The traditional solution for this problem is to create reusable libraries, a rather old technique. In .NET Framework this means creating DLLs.
When the software company develops software for itself and sells off-the-shelf products, creating libraries is usually a very good solution. Over time the company ends up with a powerful set of routines, easily at tens of thousands of lines of code. This allows the company to reduce costs and quickly evolve its products. In case a fix or an update is required, all that needs to be done is to modify the corresponding DLL and distribute it to the customers. All the software that uses the library will then be automatically updated. Another advantage is that these routines’ source code can be stored off-line; most of the developers get access only to the DLLs. This will limit the damage a disgruntled developer can cause by going to work for a competitor. Even if he illegally takes the sources he is working on, this code won’t work without the library, from which he has no source nor rights to use.
The library approach work well for ISVs (“Independent Software Vendors”). However, for custom software development, libraries can create a series of problems.
Suppose I’m the manager of a custom software development company. I’m developing a project for “ABC Company”. This system ends up having 50 thousand code lines that use my library, which itself has yet another 50 thousand code lines. The usual deal is that the resulting product belongs to the customer. Nobody questions the fact that the 50 thousand code lines created especially for ABC are their property. But what about the library’s 50 thousand lines? To whom they belong? Does ABC get their sources? If I were the vendor, I would argue that the library belongs to me and that its existence was one of the reasons that made it possible to sell the system at the agreed schedule and prices. ABC, however, may understand that all 100 thousand lines belong to them. How can they maintain a software product for which they only have half the source code? It can get worse. Suppose I gave all the sources to ABC, library included, and later I develop a project for XYZ Company, using the same library. ABC then can sue me for having “sold to XYZ something that belonged to them”. This is a very delicate matter, since both sides have plenty of reason defending their point of view, even though they are 180 degrees opposite. This type of problem can be raised beforehand and settled contractually, but it’s a very delicate subject with the possibility of poisoning the relationship between the software development and its customers, since I would force the costumers to sign a paper stating that they’d buy a system and fully acquire only half of its source code, maybe with a more stringent license for the pother half.
There is, however, a way out for this mess: instead of creating libraries the project developer can create code generators. This isn’t as hard as it seems, since there are products especially made for that purpose, such as CodeSmith (http://www.codesmithtools.com/).
By using this approach, the knowledge that would be contained in the library now becomes part of code generator “templates”. Any customer will accept that a code generator and its templates are development tools and, therefore, are an internal affair of the development company, which in turn can claim that they “made a great investment in the generators to increase its productivity and to achieve low prices”.
At delivery time, the customer receives 100% of the sources, allowing them even to hire somebody else for maintenance. However, it’s obvious that the original supplier, in possession of the code generation templates, will be in a much better position to land a maintenance contract than any other party. In other words: the customer is effectively tied to the supplier, but in a clean, honest manner.
In summary: if your company is an ISV (“Independent Software Vendors”), do rely in creating libraries: they are straight forward, allow for easy maintenance and reduce the risk of developers taking away your source code. On the other hand, if your company develops projects, use code generators. They not only bury libraries’ property discussions, they also put you in a privileged situation to win the maintenance contract.
Mauro Sant’Anna (firstname.lastname@example.org) has lived both sides of the coin, both as an ISV and as a project developer.
Eye: For custom software development, libraries can create a series of problems.