Skip to Content.
Sympa Menu

internetworkers - [internetworkers] Synova

internetworkers AT lists.ibiblio.org

Subject: Internetworkers: http://www.ibiblio.org/internetworkers/

List archive

Chronological Thread  
  • From: bethellison AT netscape.net (Beth)
  • To: internetworkers AT lists.ibiblio.org
  • Subject: [internetworkers] Synova
  • Date: Fri, 04 Apr 2003 13:55:11 -0500

Hi All,

I hope the wine was tasty and the company divine for those who went to the
wine bar last night.

Has anyone had experience, good or bad, with Synova Inc. (IT services
company)? I'm kinda getting head-hunted and I'm looking around for
information on them. Thanks.

Beth



__________________________________________________________________
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380

Get AOL Instant Messenger 5.1 for FREE! Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>From mdthomas AT mindspring.com Fri Apr 4 15:44:12 2003
Return-Path: <mdthomas AT mindspring.com>
Delivered-To: internetworkers AT lists.ibiblio.org
Received: from ms-smtp-01.southeast.rr.com (ms-smtp-01.southeast.rr.com
[24.93.67.82])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 0452C2002B
for <internetworkers AT lists.ibiblio.org>;
Fri, 4 Apr 2003 15:44:11 -0500 (EST)
Received: from mail3.nc.rr.com (fe3 [24.93.67.50])h34KdvhA019742
for <internetworkers AT lists.ibiblio.org>;
Fri, 4 Apr 2003 15:39:57 -0500 (EST)
Received: from mdthomas ([24.25.28.187]) by mail3.nc.rr.com with Microsoft
SMTPSVC(5.5.1877.757.75); Fri, 4 Apr 2003 15:41:45 -0500
Message-ID: <047c01c2faea$ea1a7950$0200a8c0@mdthomas>
From: "Michael D. Thomas" <mdthomas AT mindspring.com>
To: "Internetworkers: http://www.ibiblio.org/internetworkers/";
<internetworkers AT lists.ibiblio.org>
References: <Pine.LNX.4.44.0304041013050.4094-100000 AT tribal.metalab.unc.edu>
Subject: Re: [internetworkers] textile workers of the future?
Date: Fri, 4 Apr 2003 15:43:57 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-BeenThere: internetworkers AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: "Internetworkers: http://www.ibiblio.org/internetworkers/";
<internetworkers AT lists.ibiblio.org>
List-Id: Internetworkers: http://www.ibiblio.org/internetworkers/
<internetworkers.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/internetworkers>,
<mailto:internetworkers-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/internetworkers>
List-Post: <mailto:internetworkers AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/internetworkers>,
<mailto:internetworkers-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2003 20:44:12 -0000



> "No offense, guys," Holcomb told his co-founders, "but programmers are the
> textile workers of the future."

Well... there are differences. First, textile workers make very few decisions
about the end product. On the other hand, a programmer's value is in how they
make decisions about solving the task. What kind of data structure should I
use? How should this object interact with another object? Think of it this
way... most any algorithm is going to manifest some decisions in the form of
conditional logic (if/else). While a textile worker makes no or few decisions
that impact the end product, the programmer not only makes decisions but is,
in fact, encoding decisions.

Software is never as simple as "we need a web based inventory system
customized to our needs." It's definitely not as simple as "we need 4000 dozen
panty hose of this type" or "we need 10000 'Down With Baddour' tee-shirts."

While it is easy to send orders overseas to the management of unskilled
workers, it's harder to do this for skilled workers. To complicate things,
Software Engineering is fundamentally different not only from manufacturing,
but from other engineering disciplines. Software doesn't exist in physical
space. It's a bunch of instructions. In some cases, a piece of software can be
considered pure technology -- a word processor, for instance. In other cases,
software is a codification of business processes -- the ever popular J2EE
inventorying system, for example. As Dr. Brooks tells us, software exists on
the same plane as poetry.
In contrast, I've worked in a textile factory and I found nothing poetic about
the experience. (FYI, it's since been shutdown and the work moved overseas.)

Now, add to the enigma that software development fundamentally changes when
your development teams have more than 5 or 6 developers.

And we can't forget that, not only do many software development projects fail,
but that it takes them so long to fail. You can be a year in to a project
before everyone puts aside their delusions and realizes some crucial
architectural requirement was missed. ("You mean, the customer was serious
when they said that they wanted sub-second response time from the web client,
but the web client was going to connect over a 56K line? Well... I guess we
should have thought more about that a few months ago... We /might/ be able to
salvage a /little/ of the existing code...")

So... shipping software development overseas is more complicated than textiles
because software development is harder. The greatest cost in software
development isn't the hourly wage of the programmers if you have to scrap 6
months of work and redo it. If your software is of such low quality that you
can't get a reference customer, it doesn't matter what hourly rate you paid
the programmers. There are so many ways to waste money on a big software
project. The pay rate for the programmers seems an obvious target, but is
often a red herring.

The biggest challenge in medium-to-large scale software development is
architecting and managing software projects. The challenge isn't diminished by
having programmers on the other side of the world.

A company can screw up the management and architecture regardless of where the
programmers sit. Stick an out-sourcing relationship in there -- a corporate
wall between the programmers and those driving the project -- and perhaps it
is even more likely. Nevermind that a company that outsources isn't building a
competency in software development. The state-side company may own the
intellectual property, but who has the power in the relationship? This is less
true if the code is clean and well-documented, but often the code coming back
is spaghetti.

Code monkey jobs will go away. The programmers-as-artistes are mostly doomed,
too, unless they are lucky enough to get in at the prototype level. But in
picking enemies, one can't look just to the coding brothers "over there." As
industries mature, they mechanize. Software engineering, in particular, moves
in the direction of higher levels of abstraction. Thus, design patterns are as
much of an enemy as Bangalore.

There are still so few people that really know how to architect and manage
software that there is plenty of opportunity left in the software industry.
Software engineering is moving inevitably away from chaos. It is immature, as
engineering disciplines go, but can only get better. The American code monkey
may be doomed, but that doesn't mean American software is.

Can outsourcing overseas work? Sure. Lots of things can work. It does more or
less require a Waterfall/RUP style development model. RUP favors business
applications, such as the inventory system. RUP isn't as good at pure
technology/infrastructure software -- that's the domain of XP and Agile. But
for projects that should use RUP anyway, outsourcing overseas could even
improve the end result b/c it enforces the documentation and the separation of
the different phases.

Regardless, cost isn't the most important factor facing the software industry.
It's quality. Software quality is ultimately a management and architecture
problem, not a financial problem. You may be proud of how the numbers came out
in the spreadsheet, but software that is poorly designed and implemented is
worthless to the state-side companies, their customers, their stakeholders and
their communities.

The threat to the American software industry isn't overseas programmers --
it's a lack of focus on quality. The threat is being concerned only with the
bottom line without the realization that, without a quality product, the
bottom line will disappear along with the rest of the enterprise.








  • [internetworkers] Synova, Beth, 04/04/2003

Archive powered by MHonArc 2.6.24.

Top of Page