Software the way of the textile industry?
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.