Artistic Ownership

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.

The Art in a Game

Most of the software developers I know enjoy playing some kind of computer or card game, and they all gain some insight into good creative practices as a result. My muse is FreeCell and here are the lessons it has taught me:

Be aware of long-term problems
Sometimes a key color-number combination, such as both black 10's, can be near the bottom of separate piles. This inhibits your ability to complete long strings of builds in any column. Avoid making the problem worse by burying the color-number combination deeper. You can also end up with two of the same color card in the same pile. Don't just focus on one of the long-term problems: be aware of both of the long-term problems.

Take advantage of short-term opportunities
It is probably a good idea to face an ace (or one of the next cards for the home pile) by just moving one card up to a FreeCell, as long as you have other moves afterward.

Use mid-term strategies
Don't focus on the long-term problems (although be aware of them) and don't focus on recklessly moving cards up to the home pile. Rather, take the mid-term strategy and capitalize on long builds and emptying columns. Keep variety in your hold cards.

Maximize flexibility
Given the choice between moving cards home and gaining the flexibility of an empty column, choose greater flexibility. Think twice before leaving yourself only one open FreeCell. Patience is a virtue.

Think ahead
Plan ahead for what a move might enable -- does it allow you to open up another FreeCell or mitigate your long-term problems?

Use the hidden force
Sometimes the answer lies with forcing cards home biasing a single suit. This might be alright if it increases your flexibility elsewhere.

Be persistent
When you are stuck, take a break and do something else so that you can return later with a fresh outlook.

Know when to bail out
Sometimes a deal is just too difficult. Know when you are "in over your head" and bail out so that you don't waste your time.

I'm sure that these are all metaphors for certain things you encounter during the development cycle, but find your own metaphors in your own games. You don't have to be good at any game in order to learn its lessons, but you do have to play at it occasionally.

Artistic Standards

SOPs (or as we often call them nowadays “best practices”) get the usual bum rap but I like them as an educational tool. Standards and best practices are fine to the extent that they promote a safe and productive workplace without adversely affecting a sense of job security. For example “Always use camel case” is a good standard to improve productivity. “Keep your source code in three places” is a best practice that enhances safety.

Wielding standards like an axe over your employees’ heads will only create defensive animosity. I prefer to use them as search terms when I want to find a template or an example to share with somebody. For instance I might Google “best practices SQL maintenance” and see what it returns.

If your employees feel however that the purpose of your standards is to turn them into interchangeable cogs then at best they will only implement them halfheartedly and at worst they will spoof compliance. Make positive, non-corrosive best practices your standard operating procedure.