Do programmers create intellectual property or merely transform it?
The late mathematician Paul Erdös described a mathematician as "a machine for turning coffee into theorems" (Hoffman, P. The Man Who Loved Only Numbers: The Story of Paul Erdos and the Search for Mathematical Truth
. New York: Hyperion, 1998, p. 7)
Once I stopped chuckling at the thought of programmers turning coffee into code, I was siezed by a question: do programmers create intellectual property or merely transform it?
There is a marked difference between creating IP ("the creational model") and transforming IP ("the transformational model").
I'm going to hand wave over whether producing software is like making things in a factory. Let's grant that it may be: that doesn't affect whether programmers create or transform IP: if producing software is like a factory, we are now arguing about whether programmers produce the raw materials
or simply work the machines
In this model, there is IP that comes into the factory (perhaps in the form of "requirements" or "design patterns"), it is transformed into bits by some process, and the result is a software product of some value to consumers (by consumers I mean the users, stakeholders, and "product owners", not consumers in the broad market sense).
If programmers create IP, their ideas, designs, and problem solutions are part of the raw materials of the eventual product. If the quality of their ideas is poor, no wonderful practices or processes will save the finished work: poor programmers necessarily produce finished work of low value to its consumers (be they customers or stakeholders).
On the other hand, if programmers merely work the process, transforming IP, then the value of the finished work can be highly insulated from the quality of the programmers, just as minimum wage employees can be a part of a rigidly controlled production process. Poor programmers can produce finished work of acceptable or even high value to its consumers, provided the right process and tools are in place.
I've just talked about the effect of poor programmers in the factory. What about good or even great programmers? What about the mythical hacker? What happens when you use great programmers?
If programmers create IP, then great programmers produce great products. Of course, it is possible to screw this up with incredibly poor process (imagine a factory that collapses on its workforce), but having great programmers drives the value of the finished product on a polynomial or even exponential basis.
On the other hand if programmers merely transform IP, then great programmers will have very little effect on the value of the finished product. While they might finish work a little sooner with fewer defects, these benefits will not translate into higher value for consumers. Their efforts are somehow wasted.
I hear arguments for both models. I see this type of thinking reveal itself in the attitudes recruiters have when offering me candidates: "She has 5 years of C++ and three years of Unix, she has the experience you need."
The implication is that programming is a job with specific tasks and rote methods to be applied, like assembling parts in a factory. Requirements come dribbling down the conveyor belt, you apply the text editor and compiler tools, and the conveyor belt takes your work down the line to QA.
There are voices expressing dissent with the transformational model. One vociferous
example is Joel Spolsky
. Although he insists that API experience is necessary, he also insists that programmers be smart and get things done
If I look at companies where programmers work, I see some places where the quality of the programmers (and their management) make vast differences in the value of the product they create. I also see others where the quality of the programmers makes little or no difference.
For example, start-ups need the best people they can find. Forget time to market, you have time to the next round of funding to deal with. People that get it, that can write robust software with high quality in impossibly little time can make or break a start-up, especially in this time when money doesn't rain from the skies.
On the other hand, some ISVs have relatively mature products with modest growth plans. I've heard at least one such company owner saying he'd rather have modestly skilled people with little appetite for solving hard problems. I suspect he's built his business in such a way that adding great people won't double or treble the value of his product.
And if you look at a business that isn't even in the software business, the outlook is dismal for programmers: do you realy think that delivering a big bank's application in half the time really makes a difference? Before you say "every bank wants to save $500,000 on their next big project," ask yourself why so many of them hire IBM Global Services. Not to save money.
Maybe it's because the real value of the project as measured by the people who fund it is measured in political points. And programmers don't generate politicial points, so they can't add value to the stakeholders.
So in the end I think that there's a continuum between programmers who create IP and programmers who transform IP
. The difference is driven by characteristics of the environment. Specifically, it isn't "politics" or "culture" at the end of the day. It's the potential for the finished software to add value.
What does this mean if you're a software developer? If you really believe you are great, you must search for an environment where you have the greatest leverage. That's where you're going to make the greatest contribution.
Here are some key questions that have worked well for me in the past when evaluating opportunities to add value:
- Can you quantify the difference between failure, acceptable, and great performance of the project to the company? (Not yourself personally: if the project is high risk, high value, you'll have a great opportunity no matter what role you take)
- Who are the stakeholders in this project (who has the athority to make major decisions)?
- What is the impact of a project failure to the accountabilities of the stakeholders? (You won't get a straight "they'll be fired" answer in a job interview, but you can certainly get a feel for whether they care one way or another.)
The first question establishes whether there is in fact a wide range in expected outcomes of the project. If there is very little range between acceptable and great performance, then you are dealing with people who believe (rightly or wrongly) that programmers trasnform IP and that there is no opportunity to add value other than keeping your seat warm and following orders.
The second and third questions establish whether the factory's roof will stay on. The primary impediment to providing value in an otherwise promising environment in meddling from people who are not committed to the success of the project. And the main reason for a lack of commitment is having the authority to direct the project without being held accountable for the result.
Again, I believe that some factories provide an opportunity for great programmers to create IP, but some do not. And although I've cut myself short, I believe that it is possible to determine whether an environment will allow great programmers to create IP through judicious examination.