The managers at many places I have worked confuse the fruits of our work (lines and lines of programming code) with “intellectual property” and with knowledge. It is a convenient deception, but it ultimately causes more problems than it solves. Let’s take a look at precisely what these concepts are, why code and knowledge get conflated, and the problems that ensue.
This is somewhat akin to confusing traintracks with a railroad. A manager walks in and says “oh, that guy is a direct path to Denver, that guy goes to our hub in Chicago.” But a railroad is a whole lot more than traintracks. It is also the locomotives, semaphore crossings, stations, leased rights of way, you get the idea.
“Lines of code” is a semi-fluid corpus of rules and instructions that implement business logic. These change as customer or management needs allow and they also get modified in reaction to bug fixes and refinements in technology. They are like traintracks. In nearly all cases the software code is the property of the owners of the company. So sure the railroad owns the traintracks. Yet there is so much more.
In the context of software development “Intellectual Property” is actually a narrowly defined term. Occasionally it may be a patent, but for commercially marketed software it is more likely a copyright. Most internal-use software (the bulk of what we create) is Intellectual Property by means of “trade secret” and employment work-for-hire agreements. So these are like the leases held on the rights of way.
The code isn’t an “asset” in the sense that a physical piece of property is an asset; it lacks a particularly liquid “market” and the rules and peculiarities it encodes keep little value when transferred to a non-related owner. Selling your traintracks to Australia doesn’t do them much good.
“Knowledge” in this context encompasses three overlapping concepts. First it is a domain-specific understanding of how things are supposed to work conceptually or legally. Second it is the cultural understanding of who is proficient at maintaining what. And third it is the historical insight into how things evolved to reach their current state. Software developers employ this knowledge (which resides primarily in their heads) to produce lines of code from the influx of rules, regulations, requirements, and bug reports. So the knowledge is the locomotives, semaphore crossings, and stations.
It is convenient for a manager to jump from the work-for-hire agreement to the (mistaken) impression that he “owns” the knowledge in developers’ heads. In this way he conflates the human “resources” through the midpoint of Intellectual Property to the endpoint of an “asset” that he owns and manages. He confuses the traintracks with the railroad. Although convenient, it is wrong in that it loses pieces in the translation, creating dangerous side effects. It is like thinking you can pick up the traintracks, move them to India, and suddenly have the Southern Indian & Pacific railway.
Knowledge isn’t transferable nor is it intellectual property. And if you move people from their areas of expertise the company effectively loses their knowledge. Sure it still owns their code, but after the company saddles somebody new with maintaining the code they have to reacquire the knowledge of how to do so. They have to relearn how to run the railroad.
