Flutterby™! : Economics of Software 2005-05-13 16:57:45.5804+00

Economics of Software

2005-05-13 16:57:45.5804+00 by Dan Lyke 2 comments

A must-read, especially if you're mulling the future of software development as a career: Jonathan Shapiro on the future of programming:

It's not that the US has a "tech hostile" environment. It's that the laws of global economics are hostile to expensive providers.

The right question isn't "How do we keep programmers employed?" The right question is: "How do we change the economics of software?"

(Via Hack The Planet)

Recently, I've bought (OK, The people I was working for) a LOT of software, and the big issue was getting them to pay for things they need. I had to reformatted the web designers PC twice to reload the Adobe, Photoshop and MacroMedia free trial packages. Let's not even discuss the M$ Server licenses, SQL Server's.. etc.. etc.. etc..

I both HATE that companies do the 'registration' stuff they make people do to be 'legal' and 'activated' and also understand the reasons they do.

And saying that, I just bought RedHat Enterprise 4.0 for my new production web server because I want to support RedHat and appreciate what they do, but also just installed CentOS on my two backup servers because I need to be 'tight' with money right now.

It's really hard to shoehorn "programming" into a single market like that. What the folks do at Microsoft to create the next version of Windows is very different from what meuon does to make a web page go and it's very different from what Dan does to make a graphic widget for the Mac. And this is all light-years different from I did at McKee Foods to help monitor Swiss Cake Roll production. Some of the tools are the same, but the actual work is very, very different.

In the end, it's not about the tools or who does the work, it's about communication. At Microsoft, everyone has to be brain-washed to think the same way to be able to walk in lock-step to produce a semi-coherent project (that's why Microsoft hires almost exclusively out of schools and not "seasoned" experienced programmers). And there, communication is key. They have to analyze user patterns and document them so they get into the design of the next revision. The design has to be thorough enough so that documentation can be created at the same time as the software - and the software actually come close to matching the documentation when it's all complete. If Microsoft gets good enough at the design and documentation process, the actual programming can (and some probably has) move overseas. But I think, for whatever reason, Microsoft has found it more effective to keep even that portion of the job close to home. Probably to better control the minds of their programmers with free sodas and lunchtime soccer. Besides, Microsoft's profits show that they don't need to lower their programming costs to continue to make it.

Meuon lives in a "make it work" world. Where he has to somehow figure out what the customer needs (something they usually don't even understand). Likely, figure out what the hell the last guy did. And then try to cobble together tools so that the company can get function ASAP. He has to communicate with ghosts, so to speak. The ghost of how the company should run and the ghost of what the last guy did. He is focused (and paid) just for bring the system to life, albeit in a Frankesteinian fashion and not really paid to make sure anyone else can figure out how the hell it works. Meuon's job will never go overseas because the people are never able to put the forethought into the job to send it overseas. And what they want to do usually hasn't been done before, so there isn't a single shrink-wrap solution.

Dan lives in a world where, likely, artists can explain what in general they want. Dan understands visual art well enough to be able to hear that communication and implement it in a functional form on the computer. This is similar to Dan's mentioning before why there are fashion production shops in the high-rent Bay Area. Sometimes the people doing the design need to communicate directly with the people doing the work. They don't have the time to formalize the communication well enough to be able to allow the work to get that far out of hand.

At McKee Foods, we spend day and night inside a highly customized version of a large Oracle application. McKee Foods has a very proprietary form of accounting and process management. The communication has to be very direct and first-hand. If they followed more normalized practices, they probably could leverage more standardized software solutions and cheaper programming labor. And you can bet they've done that math already and decided it was in their favor to pay decent wages to a local programmer (not to mention, they actually have a corporate ethic that encourages paying good wages to local labor - and somehow they manage to make a profit).

At BlueCross/BlueShield they used a different ploy. Local Americans were hired as project managers - people to communicate with management and others. Programmers were brought in from India on green cards at less than 1/2 the salary of a comparable American programmer. The programmers were managed by the Americans who were made to understand that the tech help should be treated as 1. replaceable and 2. not going anywhere on their own volition because BCBST sponsors their green cards (i.e., indentured servants).

Programming comes in many flavors and the chore of translating code spec into code can probably be shipped overseas. But the communication required to generate the spec, or the communication required to code without spec can't be sent overseas. Realize that programming is communication and you'll be OK.