Immovable Object versus Unstoppable Force: Capex and the Marginal Cost of Production

One of the courses I study in the Farmyard Podcast University is economics. I like making sense of the world, and sometimes economics help make sense of the world. Sometimes. Sometimes it seems flatly contradictory. Here is one of those cases.

The theory of production states that in a competitive market, prices will stabilize at the marginal cost of production. That is, if I am a farmer with a bunch of wheat, I will be willing to sell my next kilo at the cost to raise that additional kilo. If seed, fertilizer, and diesel cost me $10 for that kilo, I will rationally take anything more than $10 for it. Since lots of other farmers are also competing to sell wheat, the price will fall to $10. I would be a chump to insist on a higher price and risk not selling at all. I would be a chump to sell for less than my cost of production. Price = marginal cost of production.

The theory or production is used to “logically” justify a price of $0 for information. Since the marginal cost of production (the amount to distribute the next download) is essentially zero, so the story goes, the price for information will tend to zero.

Enter CAPEX

This theory takes a very narrow view of economics. Somebody has to pay for the tractor and the land. In this model, such costs get paid for out of an irrelevantly small slice of the price.

Businesses divide the money they spend in to capital expenditure, CAPEX, and operational expenditure, OPEX. CAPEX is money spent in anticipation of future gain, like buying a new tractor or writing a programming tool. OPEX is money spent in anticipation of immediate gain, like buying seed or paying this month’s bandwidth bill. The distinction between CAPEX and OPEX is important for tax reasons and because balancing the two in various ways can offer different business models.

OPEX is really our friend the marginal cost of production by a different name. Bringing CAPEX into the picture highlights the absurdity of the “price = marginal cost of production” theory as OPEX trends to zero. That little “capital tax” added to every price becomes increasingly significant. What happens when price = marginal cost = $0? Like quantum effects, once you reach a certain scale the rules change. The Newtonian economics of “price = marginal cost of production” are overwhelmed by the need to finance the upfront capital. The form of solution to this has yet to emerge.

Is This Really a Problem?

One of the factors that has kept this dilemma from being a problem to date is increasing capital efficiency. A programmer today can produce software for much, much less than he would have required for the same functionality even ten years ago. In fields like journalism or music, the cost of doing an okay job has likewise fallen dramatically.

The word “okay” is important in that last sentence. There is a difference between an article written by Malcolm Gladwell (on this very topic) and one written by, well, me. But if his costs money and mine is free and you don’t care enough about the difference, he can’t charge for his. I don’t care about charging for mine, because I make my money on, on, on… I’ll get back to you on that.

Cracks are appearing in the system. One of my pressing needs is an efficient environment for collaborating in real-time on code. Many projects have started to provide such functionality, but most (all in the Eclipse world) have stalled short of solving the problem. Increasing capital efficiency in this case can’t overcome the size of the task of solving a difficult programming problem. The capital just isn’t there to solve the whole problem. A group of smart, poor graduate students can’t muster the capital necessary to solve it and a VC would have to be crazy to invest in it, given that no one will pay for a solution. And so a socially, economically significant problem goes unsolved.

I don’t have a resolution of this dilemma. CAPEX is immovable but the pressure for “price = marginal cost of production” is unstoppable. One argument was that in a world of abundance, things that couldn’t be replicated easily, like one’s own physical presence, would increase in value. I am not finding that to be true, but I’m experimenting with selling a remote pair programming session. I’ll get back to you on how it works. In the meantime I have some good ideas waiting for capital, I just can’t promise any payoff. I know I’m not alone.

24 Comments

David RyanJune 29th, 2009 at 10:29 pm

You hit the nail on the head of why so many ambitious software projects fail, or take a lot longer to see the light. Thanks for writing it so clearly and consisely. I’m also waiting for capital, but continue to tinker while its not there.

I think the cracks you’ve outlined are more like gaping holes in the software industry. Open source has a fantastic ability to perform incremental changes to a system already in place. However, there’s only a few companies and university departments with the capital in place to make major leaps. Obviously Apple are one such company that has the tenacity to put the hard yards into new technology. Eclipse is another where IBM took a large amount of effort and provided a base for open source to build upon. But these are really so rare in such a large industry.

If you find a solution, please let me know. :)

ShonzillaJune 30th, 2009 at 12:55 am

I wonder what’s up with all those remote real-time pair programming solutions for Eclipse and other IDEs – most notably Cola?

I feel an urge to drop my 2c… :-)

Compared to farmyard metaphor, I believe IT is in a lot less favorable and riskier position due to its natural exposure to innovation. As the price of hardware (once considered a significant part of CAPEX) is driven down by innovation in the respective fields, the price of software has become an issue until open-source has become such a viable option for solving increasing number of IT problems. Since hardware is so cheap nowadays compared to talent and software they produce or customize, I would approximate CAPEX in IT with costs needed to produce premium features offered in software. Companies like mobile phone manufacturers (most notably Apple) and mobile operators are still succeeding to squeeze more money out of us, because smartphones (where telephony is almost the necessary evil) are the latest hardware making people spend more in CAPEX.

What this seems to have roughly boiled down to is the pressure to innovate in customer acquisition (e.g. using social media) and pressure to invest in CAPEX to be able to increase the OPEX margin that is produced by selling software solution based on increasingly open-source software that has a diminishing barrier to entry.

If I have taken your metaphor too far, my enthusiasm is to blame. You got me thinking.

At any rate, I’m curious how your pair programming experiment will succeed. :-)

Cheers!
Shonzilla

Stuart GaleJune 30th, 2009 at 1:21 am

Do you think that your need for an efficient environment for collaborative programming could be solved by Google Wave’s approach to collaboration?

Andy PalmerJune 30th, 2009 at 3:53 am

You make a good point about Malcolm Gladwell, but I think there are more conclusions than the one you came to.
Malcolm is forced to give his article away only if he is competing with you, for your audience. And, as you’ve said, your audience doesn’t care about the difference, so is likely to value his work less.
He therefore caters to his own market, who do care about the difference and will pay for his work (although they may still pay an interest to yours)
Likewise, I could offer a pair programming session on eBay, but it is unlikely that my market would be the same as yours. You have an established reputation which adds value to your offering, above and beyond any difference (perceived or otherwise) in our programming abilities.
Adding a link to Infinitest on the subscription page of JUnitMax is another example of this kind of thinking. You add value to your offering by recognising, and being (or at least, appearing) unafraid of, this free alternative.

Your reputation cost you a certain amount of effort, this is your CAPEX, and you are able to trade off it in a number of ways. Keynotes, endorsements, signature series are examples of this. Are there ways that you can leverage this capital to enable your current ideas?

KentBeckJune 30th, 2009 at 4:50 am

Yes, I think Wave could provide the backend conflict resolution mechanism for multi-local editing. The APIs they’ve published so far aren’t extensive enough for even a little prototype, though, not that I could figure out.

Eric RizzoJune 30th, 2009 at 6:40 am

I agree with Andy that different target markets make a big difference; as I glanced at your paring auction I was thinking, “I wonder how much per hour my own skills would garner in that kind of market?” Obviously, name recognition, previously published work, and the sometimes-near-cult following of the XP/Agile movement are going to impact the market price for the service coming from Kent Beck, as opposed to an “identical” service coming from Eric Who?, but maybe I have a different reputation to leverage… hmm, I might have to give that a try since I am currently unemployed and not under contract…

Eric RizzoJune 30th, 2009 at 6:43 am

Oh, and by the way…
Looking at the profile photo used in your eBay auction made me wonder…why is it that we’ve never seen Kent Beck and Jack Bauer in the same place at the same time? Jack never smiles, so it’s hard to say for certain, but they look an awful lot alike. Hmm…

André DhondtJune 30th, 2009 at 7:26 am

As Andy Palmer hinted towards, Marginal Cost of Production can be fought off by Unique Selling Points. If my product has functionality that yours doesn’t, and the customer values it, then they’ll pay more for mine. Then I start to think about the ecosystem growing around social networking sites–the hudreds of add-on products (clients, organizers, editors)–while they’re being “sold” for nothing, they’re still competing in a way that fights against commodity pricing. So, is there a way to convince people to pay for these Unique Selling Points? Maybe not in software, but the idea has traction. Look at Local Motors, who is making product lines in batches of 50 or 100. http://www.buzzmachine.com/2009/06/02/the-new-detroit-isnt-detroit/ or at Zara http://www.allbusiness.com/construction/4266194-1.html . Now we just need a visionary to help us figure out how to do this in the software world.

KentBeckJune 30th, 2009 at 7:43 am

Unique selling points are a powerful tool to encourage monetization through scarcity. Capital efficiency works against unique selling points, though. The cheaper software is to write, the easier it is to copy, the harder it is to maintain a leadership position.

Data is one way to differentiate that is hard to duplicate. Sources of unique data are still able to charge as long as the data is valuable. The future of a tool like JUnit Max would be in collecting detailed usage statistics from a million programmers. Of course, to get data from a million programmers the tools have to be free… And where will the CAPEX come from to prime the pump?

KentBeckJune 30th, 2009 at 7:44 am

It would be interesting to see statistics from a free market for pair programming participation. “I’ll short the April Beck futures and buy a call for the March Rizzo 90s”.

DavidJune 30th, 2009 at 2:12 pm

“selling a remote pair programming session.”

Oooh! Free shipping!!

:)

I think its a great idea. No. I think it is a necessary idea. We’ve got to figure this stuff out. We should have figured it out already.

Sebastian Kübeck paJuly 1st, 2009 at 5:40 am

Kent, stupid question: Why don’t you produce and sell E-Learning material?
The advantage is that you can produce it once and sell it as often as you want. For a pair programming session, you need an eclipse plugin that you don’t have and you have to do that for each client separately. That doesn’t multiply so that you have to make it really expensive to get profitable.

KentBeckJuly 1st, 2009 at 5:56 am

I thought I was the one who got to decide if it was a stupid question or not :-)

E-learning is a scalable business model. Companies like Industrial Logic have put a lot of effort into their e-learning products and are seeing good results. However, it is a capital intensive business and it requires a real sales organization to make it profitable (you need to sell in bulk to large companies). Finally, while I have done course development from time to time, it’s not really my calling. I wouldn’t mind a business that mixed in course development, but I’d rather not rely on it solely.

Selling a pair programming session is more of a “minimum viable product” in the lean startup sense for me. I wanted to see what kind of interest there was out there and what the general price range would be. In five days we’ll all find out.

Smart question :-) At least, it made me think. Thanks.

Scott LewisJuly 1st, 2009 at 11:15 am

Hi Kent.

I was a little surprised with your statement that “Many projects have started to provide such functionality, but most (all in the Eclipse world) have stalled short of solving the problem.”

Of course this statement depends upon a specific definition of ‘the problem’, but just to point out:

We on ECF [1] have done a fair amount of work on real-time shared editing and operational transformation [2,3,4], and this work is continuing in earnest over our next release cycle [5].

This doesn’t, of course, represent solving the ‘entire problem’ of supporting distributed pair programming or supporting collaborative programming, etc, but we do feel that this work…in combination with a number of other elements we already have in ECF (e.g. presence/IM, chat, voip, rt team provider, screen sharing, file sharing, plans for integration of VNC [6] , as well as a Google wave provider [7]), does present some opportunities for low-cost, well integrated, innovative solutions in this space.

There are folks already building educational systems based on ECF (e.g. Coffee project [8]) and in this case, there are now contributions from these folks coming back to ECF. We welcome both open source and non-open source solutions built on ECF.

Further, we are moving this work aggressively forward via greater focus from ECF committers, as well as many more community contributions/involvement. We would of course welcome your and others’ participation/contributions as well. If interested in this, please consider joining the ecf-dev mailing list and expressing this interest [9].

Scott

[1] http://www.eclipse.org/ecf
[2] http://wiki.eclipse.org/DocShare_Plugin
[3] http://www.eclipse.org/ecf/NewAndNoteworthy.html
[4] http://live.eclipse.org/node/543
[5] http://wiki.eclipse.org/ECF
[6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=239854
[7] http://eclipsesource.com/blogs/2009/06/15/google-wave-and-ecf/
[8] http://www.coffee-soft.org/
[9] https://dev.eclipse.org/mailman/listinfo/ecf-dev

KentBeckJuly 1st, 2009 at 11:40 am

Scott,

I didn’t intend to diminish the efforts of ECF. I am aware of what’s going on there. However, if Saff and I want to pair on JUnit, I can’t pull anything out of the ECF box to let me do that. That’s what I am looking for.

Scott LewisJuly 1st, 2009 at 12:00 pm

Hi Kent,

‘Pair on junit’…can you describe this use case a little further? We do have some facility in ECF for sharing state information (e.g. test state) in real time (and this is used for the rt shared editing among other things), so although we don’t have something finished here it might be an easy addition for yourself/someone so familiar with junit impl/internals. Also, FWIW, there’s this work on distributed OSGI testing that is now underway http://wiki.eclipse.org/Distributed_testing_framework_based_on_ECF_RFC_119_D-OSGi

KentBeckJuly 1st, 2009 at 2:06 pm

I want the experience to be as zero-touch as possible. Hence the use of GitHub as a connection point, since that’s something we already do.

1. At some point we have to register somewhere. Make this as painless as possible (OpenID, Facebook Connect, whatever)
2. We each say, “We’re working on this GitHub project”
3. Now we see each others’ edits in real time. It’s semantically identical to sitting together and working on one machine. We’re also connected by audio and/or video.

From what I understand, ECF is intended to facilitate this kind of interaction. What it doesn’t seem to have is the package that puts all the pieces together. If such a package was an important goal, I would ask the team to commit to only coding using the collaborative tool environment. This would be grindingly slow at first, but I suspect it would rapidly become practical. Never underestimate the power of a frustrated geek :-)

Jeffrey FredrickJuly 1st, 2009 at 3:44 pm

I happen to be reading Wealth of Nations and there’s a section in there that talks addresses open source pretty clearly (though in this case it is socks). The gist is that if people who are producing a good will do so as a hobby or as a source of additional income after their supporting job that you can’t compete on price.

It turns out that creating tools for developers is something that many developers are happy to do as a hobby. So the tool market for developers is a crappy place to try and make a living.

But there are lots of other markets out there.

Michael HungerJuly 1st, 2009 at 3:47 pm

I don’t know if the real time collaborative editing (also possible with the online Bespin-IDE) is so helpful in pair programming. If both parties type at the same time both are focusing on their stuff and not watching what the other is doing. I think the roles of driver and navigator distribute the responsibilities quite nicely. Having different brain parts active for the two of them.
In the real world you also have just one keyboard.

What I’d second is better support for pointing out things or stopping the other one doing stuff and getting into discussion/thinking. What also would be interesting is instant branching like git does but at a micro level to try out several solutions at once and see how they fit/feel/work out while keeping the current one.

But perhaps collaborative editing is attacking the wrong problem. How many developers you know really participate in pairing? How many can do it and how many want to do it. Changing the culture there is imho more important than new shiny tools.

Regarding your CAPEX discussion. Isn’t that the same problem we have when being compared to the civil engineering discipline or production. That the production phase of software development is actually compiling, building and delivering the binaries? That the analysis/design effort (of production) is what we’re really doing? And what is the cost of that? Its the hourly cost of the people doing the work which reflects the production costs. And this is part of CAPEX (imho) for production as it is upfront capital investment and not operational production costs. So CAPEX increases more and more? Whats the matter with artist or artisans? What are their works valued for – just the time they spend on it? Or rather the quality, the value they deliver and the reputation attached to the creator?

I think we should try to get away from the software produced anonymously by typing mokeys to product that are valued for the same reasons and that are signed by their creators. Then the value of contributions made by those recognized and recognizable people will never be zero.

KentBeckJuly 1st, 2009 at 5:35 pm

Jeff,

You and I have both experienced that developer tools aren’t a great business opportunity, haven’t we? Ideally I would find a related topic (see Eric Ries’ “pivot” concept), like testing tools for testers, say, or reporting tools for project managers. However, I don’t have one of those in mind. I’m also willing to go further afield, but again, I don’t see any prospects on the horizon.

KentBeckJuly 1st, 2009 at 5:45 pm

My experience with remote pairing (>1000 hours at this point) is that the difficult conflict merge scenarios aren’t that important. They have to be implemented for completeness. Mostly what I need is immediate feedback on the local screen when I’m typing and the same for my partner. The asymmetry of screen sharing means that one person does most of the typing. Most of the time only one person will be typing at a time. I suppose the simplest conflict resolution strategy is to undo both party’s typing if a conflict is detected. Then we can have a chuckle and a conversation about who will be in control. That’s a good enough idea that I’m tempted to implement it.

Willem van den EndeJuly 2nd, 2009 at 7:03 am

Kent,

Screen sharing can be made symmetric. My solution to the ‘local pair partner has the advantage’ is to install vnc on a remote server (with much better internet connection than either partner has) that both partners log in to, so neither has the advantage.
I noticed Andy Palmer and Antony Marcano use dimdim.com, which should be able to support symmetric remote pairing (I wasn’t successful with that yet).

KentBeckJuly 2nd, 2009 at 7:36 am

If the parties are close enough, the shared third machine is a good solution. I am often 400-500 ms away from my programming partners (that pesky speed of light :-) . I haven’t tried a shared third server in such a situation.

Kragen Javier SitakerJuly 14th, 2009 at 3:02 pm

The marginal cost of production isn’t just OPEX; risk-adjusted depreciation on CAPEX is part of it too.