Re: Economic cycles, offshore programmers, software quality
Warning! This is a very long post!
When I visited PTEC a couple years ago, management was suggesting that compensation for BIOS engineers in San Jose was skyrocketing. At that time it was difficult to find a decent motel room around San Jose even at $100 a night.
What a bargain! How can they afford to rent a hotel room for 1/3 the cost of Manhattan when real estate is nearly as expensive? Perhaps that extraordinary efficiency is the reason the computer industry is concentrated in the Bay Area rather than in N.Y. or Boston.
If you told me two years ago that PTEC's products were essentially worthless and service profit was the major determining factor of success for PTEC, I might have sold my shares when the insiders sold back then.
I couldn't find the posts, but I recall that you were appalled when I suggested that Phoenix is more like McDonald's than a technology company. Given the criticism from Jules Garfunkel of the IBM services business, he might also be appalled. But, I suggest you guys examine the 80 month chart of the pure services business of Cambridge Technology Partners at
techstocks.com. They've grown 50% annually for many years and are now in the S&P 500 despite going public after Phoenix.
Where are we now in the economic cycle for BIOS engineers?
BIOS engineers don't exist in a vacuum. Their main talents are writing assembly code and reading chip manuals written by illiterate electrical engineers telling them which bits to flip. Those same talents can be used by a lot of different industries. Given all the recent layoffs, salaries are probably leveling off. I consider economic cycles to be in the hands of the politicians and I have no way of reading their minds.
Why does it seem that the interconnect synthesizable core industry is being imported from India to the United States? What are the dynamics of that to the industry and to PTEC?
BIOS engineering is performed worldwide because the engineers have a high degree of interaction with PC vendors located everywhere. Desktop software is usually created in the U.S. because beta sites in the U.S. essentially define the feature set. Don't ask me how a German software company became successful, but this month's issue of The Red Herring has a theory at redherring.com.
Sand and VChips are split between India and the U.S., so it seems that the strong design definitions of interconnect standards and lack of strong time-to-market pressures make it ideal for Indian programmers. But, the people who created the definitions are located in the U.S. and their knowledge makes them efficient. I read somewhere that PC vendors are balking at 1394 because of the $12 unit cost, which suggests Indian development. Joe Raffa's post indicates that the products are rapidly becoming as worthless as BIOS code, so perhaps that will spur emigration to the U.S. Raj Raghavan also seems bullish on the U.S.
A guy named Ed Yourdon (http://www.yourdon.com) wrote a book in 1992 called, "The Decline and Fall of the American Programmer" (http://www.amazon.com/exec/obidos/ISBN=013191958X/002-9062506-3132814). He made arguments such as the following at "The Continuing Saga of the Decline and Fall of the American Programmer": (http://www.yourdon.com/articles/DeclineFall.html)
American programmers are 5-10 times more expensive than those in South America, Asia, and most of the developing nations. And the productivity of these offshore programmers, and the quality of their software, is often dramatically higher than ours. For nearly 30 years, we have known that tenfold improvements in software productivity and quality are readily achievable without magic or silver bullet technologies. The methods and techniques for achieving these improvements have been widely published in the U.S., but we don't pay much attention to our own preaching.
He got it all wrong. Bill Gates and others gave him a good education. So, he repudiated his earlier work in his 1995 book, "Rise & Resurrection of the American Programmer" (http://www.amazon.com/exec/obidos/ISBN=0139561609/o/002-9062...). The newer book is summarized by articles such as, "A Reengineering Concept for IT Organizations: 'Good-Enough' Software": (http://www.yourdon.com/articles/GoodEnuf.html)
Most IT organizations assume that their users would like them to develop software instantly, at no cost, and with no defects. But that's just not possible in today's world; in more and more application domains, we've been forced to accept the fact that the reengineering slogan of "faster, cheaper, better" really means "fast enough, cheap enough, good enough." In the past few months, the concept of "good enough" software has been getting a lot of discussion: the uproar over the Pentium bug suggests that it was deemed not good enough, while the surprisingly large numbers of defects that are publicly acknowledged in popular shrink-wrapped software products -- e.g., word processors, spreadsheets, tax calculation programs, and PC operating systems from a variety of the best-known software companies -- suggests that those products are good enough.
He also describes his agonizing process of being educated by Bill Gates and refrains from suggesting that he should be punished by the trustbusters:
Some purists -- especially the long-time professionals of the computer industry -- may express horror at the "flight from quality." But I think it will lead to more rational software development projects, and a more rational way of negotiating the criteria for successful projects with our customers and managers….
For an important class of software projects, that battle cry ("We'll deliver high-quality, bug-free software on time, within budget!") is still relevant: obviously, nobody wants to fly on an airplane whose guidance control software has as many bugs as our PC word processor. Nobody wants their telephone system or their bank's ATM system to crash as often as their desktop operating system. But for another class of software projects -- which is arguably far larger today than the class of "critical" software systems -- rapid delivery of the software to the customer is sometimes more important than the number of defects it contains. In other situations, "feature richness" may be the dominant factor; in still others, cost might the only thing the user cares about. |
