raganwald
Monday, August 30, 2004
  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:

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.


Labels:

 

Comments on “Do programmers create intellectual property or merely transform it?:
It seems that the Ontario government doesn't know what a programmer does either.

I was just reading the rules for collecting RST (retail sales tax) on computer related services.

http://www.trd.fin.gov.on.ca/userfiles/page_attachments/Library/3/Rsie_650.htm#A1

In the eyes of the Ontario government, it seems that the only time something isn't a taxable good or service in the computer industry is when its a custom job. Modifications of existing work or the building of applications using existing modules is taxable.

But, if a modification is a custom modification that costs more than the original program - its no longer taxable. I would then assume that if you are using open source code as a base - you wouldn't have to charge RST as any change is greater than $0. But, I digress.

Where does all of this fall in the IP debate? I'll let you you draw your own conclusions. But, reading the tax law does provide and interesting perspective.

andre
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /