Anyone who owns a software business is familiar with the steady stream of marketing pitches from Indian companies or their North American agents offering to offshore your software development to teams of talented, low-cost engineers in Mumbai or Bangalore. Lately, though I've actually had contacts from a couple of Indian software companies seeking to outsource software projects to Pikesoft. When I mentioned this to a few other colleagues, more than one had experienced similar contacts, and in one case the inquiring company wanted to fly my colleague over to India as a consultant.
I haven't blogged about it much, but my former career as an economist gave me a pretty optimistic view of globalization. I've always maintained that while competitive pressures from outside our borders would destroy certain opportunities at home, it would create others, and that the resulting churn was a healthy—and ultimately inevitable—thing. I realize my experience is entirely anecdotal, but it's interesting and encouraging to me all the same.
I've spent much of my software development career working remotely for clients, and can tell you that it presents many human challenges. Humanity evolved most of its talent for cooperation during thousands of years living in small bands who worked shoulder to shoulder, face to face for their whole lives. The Internet does indeed flatten and shrink the planet, but it's hard work to translate that cooperative knack for trust-building and creative synergy into a form that travels by optical fiber. It's also exciting when you succeed!
Thanks to Daniel Taylor at
Mobile Enterprise Weblog for hosting the
39th edition of Carnival of the Mobilists (and for picking my post about
Palm's OS plans as his favorite!) Actually, my favorite post from the Carnival was Daniel's own contribution,
Mobility, Oligopoly and Fixed-Mobile Convergence, so I'm hereby returning the favor.
Daniel looks at the convergence of fixed wireless (i.e. VoIP) and mobile wireless, including roaming between these networks and answers the question of why we don't see VoIP on mobile handsets yet. He argues that it comes down to the economics of the oligopoly: when a relatively small number of vendors supply a market with high barriers to entry and there are limitations on the consumer's ability to switch vendors they tend to price their services higher than in a "perfectly competitive" market. They also are more restrained in expanding their output and making costly innovations. He argues that this is the market that the wireless carriers operate in and that it explains why competitive pressures are insufficient to prod them toward fixed-mobile convergence.
I agree with Daniel that it's not technology that's blocking fixed-mobile convergence. And it's also not an institutional inability to innovate on the part of the carriers. But I wonder if the traditional neoclassical microeconomics of the oligopoly really captures the situation very well. For one thing, it's difficult to look at operator expenditures on their networks and say that they are restraining output OPEC-style to keep plan rates high. To the contrary, their aggressive network build-out looks like very active rivalry to steal customers from each other. 3G investment has been huge, of course. But Sprint just announced they are
expanding into WiMax so that their 3G network doesn't get congested with all the streaming data they are hoping to sell. Why would they bother spending billions on a new network if they didn't think this was necessary to compete? Verizon, too, is expanding into fixed wireless and T-Mobile is putting up hotspots all over the place in the US.
As a consumer I'd love to see cut-throat competition bring the cost of wireless down. But as an economist I know that market concentration actually makes a lot of beneficial innovations profitable that wouldn't otherwise be--especially those that involve a lot of capital investment. If the operators were selling wireless in the same kind of low-margin, unconcentrated market in which farmers sell wheat and corn I dare say we would still be waiting for 3G.
When will we see FMC? Not right away, to be sure, but maybe not at the "last possible minute" as Daniel suggests. I figure it will start to happen when one or two carriers decide they have a big enough piece of the fixed wireless action to make the first move. And scrambling for those pieces seems to be something they're working hard on right now.
In my last post I started looking at software development more or less from the perspective of the classical economics of the 18th century Scottish Enlightenment: the thought of heavyweights like Adam Smith and David Hume. In the next two or three posts I want to talk about what economists can teach us about "loose coupling and strong cohesion." For that we'll jump forward to the 20th century Austrian School of economics.
But first let me say that I'm going to try
hard not to let this get too academic. For one thing it's a blog and it shouldn't be dry. For another I'm still forming my ideas here, so I don't intend for any of this to hold up to some kind of rigorous peer review. I know I have an unfortunate tendency to be grandiose and didactic that I apologize in advance for. I'm a humble disciple of the Gang of Four and the Agile development gurus, but I'm also a recovering economics professor, so bear with me.
The title of this entry is an ironic quip you sometimes hear from economists--especially when they are trying to be clever in front of a lecture hall of bored students. What's ironic about it? It's that in that most mundane observation is hidden the great mystery that lies at the center of all economics.
Think about it: millions of meals are served each day according to the diverse preferences of countless Parisian diners, each prepared using food items and tools produced by millions of others who have
practically no knowledge of the dinner plans of each diner, the recipes of the cooks, the type and availability of tools and complementary food items required for those recipes, etc. Likewise the diners need know nothing about farming technologies and conditions, transportation or manufacturing complexities, cooking, or the plans of any other diner in Paris to be confident in their plans to have that boeuf bourguignon they've been looking forward to tonight. How can the plans of all those millions of people be coordinated so beautifully when none of them knows more than the minutest fraction of what apparently
must be known for that coordination to occur? That's the mystery.
There is no mastermind in this system. There couldn't be: it's far too complex. The knowledge that makes this cooperation possible is never centralized, rather it's distributed, an emergent property arising from each of us pursuing our own narrow ends in relative ignorance. Like a colony of termites that seems to use complex physics to regulate the internal temperature of its mound but whose members know nothing of this science, our economy "knows" vastly more than any individual in it every could. If there is a change in conditions, say a hurricane that takes out a major port, a process that
no one designed comes into play that keeps the system from collapsing: prices of certain now-scarce resources rise, consumers respond to higher prices by substituting new consumption patterns, entrepreneurs respond by moving resources to parts of the economy where prices make them more valuable (profitable), and soon the economy has redeployed human and physical resources so as to minimize the impact of the disaster.
Meanwhile back at the software ranch our own complex systems often seem not to be so effortlessly coordinated. Sometimes they seem to operate more like FEMA, right? How often do we have the happy experience of adding code to respond to a changed requirement and finding that the other modules in the project effortlessly accommodate the change? And how often do we find that the change breaks some piece of code that we knew nothing about and now have to pore through to figure out what went wrong? What's the secret our economy knows that our software projects do not?
Yeah, I know, "spare us the professorial drama and get to the point." Ok, I'll do that in the next post.
Last week I mentioned there are some interesting things to learn by comparing good object oriented software design to the structure of successful economic systems. I'm going to start taking a stab at this today.
While catching up with my backlog of Wall Street Journals last weekend my eye was caught by a front page article about the troubles Microsoft has had delivering Windows Longhorn. It was interesting to read about James Alchin trying to explain to boss Bill Gates two years ago that Windows had hit a wall that it had been approaching for years. By Alchin's own account, new Windows features were breaking so much existing code and creating so many bugs to be fixed that Microsoft would have to make significant compromises on stability, security, features, or the delivery date. We know they sacrificed (initially) some features they had planned and they sure rolled back the delivery date. We can only hope they bought some progress in the other two areas.
I'll leave it to others to snicker over Microsoft getting its comeuppance for playing fast and loose with its product development. And while I requested a copy of the Longhorn source code so I could perform a code review for this article, as of press time my calls had yet to be returned. Heh, so much the better: that leaves me free to suppose all kinds of things about how the Windows developers go about their work. When you get your own copy of the source you're welcome to set me straight. ;-)
But seriously, I feel safe in saying based on Allchin's description that the Windows teams are suffering the effects of what we call "tight coupling" between code modules. It's a problem that can plague economies as well. I'll get to "tight coupling" presently, but let me lay some groundwork for that discussion by talking about modularity as it applies to software and economies.
I was first introduced to object-oriented programming in 1988 by Don Lavoie, a professor and mentor in the Department of Economics at George Mason University, where I was studying for a Ph.D.
Don had been a programmer before he became an Econ prof, but what really interested him (and several grad students like myself) was the similarity in the way OOP proponents were describing the advantages of this new way to write software and the way economists describe the workings of the free market system. One of my great regrets from those days was my decision that pursuing the software/economics connection was a distraction from my Ph.D work that I couldn't afford. Had I not thought of the time I spent learning Smalltalk/V as a guilty pleasure I would have been in the middle of what turned out to be a pretty mind-blowing cross-disciplinary conversation that went on for several years between some brilliant programmers at
Xanadu in Palo Alto, some AI grad students at GMU, and Don's little band of
"Austrian School" economist-technologists in the GMU Market Process Center.
Here's one article I remember well that describes one of the early meetings of the economists and the Palo Alto guys. I think it gives a good feeling for the intellectual excitement felt by all involved.
As I've started spending more time writing object-oriented than procedural C code in my work, and particularly as I've become involved with Agile Development, I've been thinking about those days and wondering what happened to what we called the "Agorics Project." Sadly, Don died of cancer in 2001, a young man and a
great teacher with enough ideas and passion for three lifetimes. After grad school I lost track of student colleagues who were active in the Agorics Project. When last I Googled for signs of the project it seemed like
Mark Miller (of PARC and formerly lead architect at Xanadu) was one of the few who is still harvesting fruit from this interesting cross-pollination of disciplines.
I plan to do a little digging and see if I can get in touch with some of these old friends and their work. Meanwhile, watch here for posts categorized under "Software and Economics" and I'll try to spell out some of the connections that I think should be interesting to software developers who don't know anything about economic theory.
The first thing I will examine is what economists had to say about the object-oriented developers' "loose coupling, strong cohesion" mantra centuries before the first computer was invented.
