Software the way of the textile industry?

Eirikur Hallgrimsson
Wed, 16 Jan 2002 01:56:58 -0500

I think the reason that software development has stuck around here in the 
states is that software that actually works--actually works in real life 
at the customer site on random PC clones using corrupt live data over a 
misconfigured network--is not really a solved problem.   At least not in 
the common case. 

We've (American business we) become accustomed to software that's really 
at the Model T level.  You have to be a bit of a geek to get it to work, 
and you know you'll be needing a mechanic fairly often.   If that's the 
case, it really pays to have a short turnaround with developers who are 
native speakers of your language.

I was the outsourcing manager for a number of projects at DEC.  
Outsourcing was very popular during Digital's decline--particularly for 
products that were in final releases or maintenance situations.  I saw the 
cost situation in Israel price the Israelis out of the market, leaving 

One thing I can say from that experience is that the usual payment scheme 
creates the wrong incentives and induces friction which increases the 
overall cost of the outsourced solution....typically companies pay a flat 
rate ( N developers for M period of time, or worse yet, X amount of 
dollars flat) and that means that bug-fixing and quality suffer.   Digital 
paid flat rates for outsourced support, and it was like pulling teeth to 
get bugs fixed....because the vendor had no incentive to do more than just 
enough to keep the contract (with Digital where there was such high 
internal friction that changing vendors wasn't an easy or inexpensive 

=============== Firewall: only flames below this line ==========

If I can take on Adam's angst-ridden aspect for a moment.....
As a professional software engineer and manager of same, I was totally 
frustrated by Digital management's desire to not let us do our jobs.
I don't know where the impetus came from, but it was powerful.
It was somehow "general knowledge" that we were far too expensive to do 
product development.   It might even have been true, but the attempted 
solutions were worse....

The company would buy source rights to bad code-bases to "speed" 
development, and outsource programming work to poorly-qualified vendors 
using poorly written contracts.....  The buy-out products (buy source 
rights to a version of a commecial product and have DEC engineers 
"Digitalize" and re-badge it) were particularly embarrassing.  DECwrite 
was, um, hampered, by being based on a version of FrameMaker.    At the 
time the decision was taken to buy the FrameMaker source, they KNEW that 
all that our home team had to do was to replace the file format and 
in-memory data structures and the entire user interface.   It didn't take 
much more than 1.5X the time it would have taken to build a better product 
from scratch, but it did make sure that the design-capable engineering 
staff left the company.