RE: [AM] Demise of a 100-person company

or, more likely, the incorrect wholesale adoption of a "universal" tool.

always demand "show me" type evidence from any tool. (Even one's that I
sell! There is a lot that goes into successful use of a tool in a given
team, environment, culture, application domain, schedule crunch, etc.  No
change to an existing team happens without a price.)


-- jon



> -----Original Message-----
> From: Charlie Poole [mailto:[email protected]]
> Sent: Sunday, February 01, 2004 10:01 PM
> To: [email protected]
> Subject: RE: [AM] Demise of a 100-person company
>
>
> Perhaps the imposition of a software tool was a symptom, rather than the
> cause.
>
> Charlie Poole
> [email protected]
> www.pooleconsulting.com
> www.charliepoole.org
>
>
>
>
>
> > -----Original Message-----
> > From: Adrian Walker [mailto:[email protected]]
> > Sent: Saturday, January 31, 2004 5:28 PM
> > To: [email protected]
> > Subject: RE: [AM] Demise of a 100-person company
> >
> >
> > Hi Jonathan --
> >
> > [Adrian]
> >  > I have seen a perfectly good 100-person software company, with
> > household
> >  > name customers, that sank like a rock because of this problem. At
> >  > management insistence, a three-page Perl script was replaced
> by a huge
> >  > "does everything" object-code-only package from a vendor. 1,000-page
> >  > manuals. Configurable only by scarce specialists. The rest
> is history.
> >
> > [Jonathan]
> > >You description of the problem is unclear. Seems hard to believe
> > that some
> > >piece of code caused a 100-person company to go bankrupt.
> >
> > The company fielded a complex product that pulled data in
> various formats
> > (EDI, various XML dialects, spreadsheets...) from different companies,
> > translated it into relational form, stored it in Oracle, then produced a
> > variety of active Web pages.
> >
> > The translation from the various formats into to relational form was
> > originally done in three pages of Perl, which was very easy to maintain,
> > and to extend as new formats were added.
> >
> > However, a vendor persuaded the CEO that the company should use their
> > "universal data mapper" instead of the Perl script.  This turned
> > out to be
> > a complete bottleneck.  Strangulation of data-in, rapid disappearance of
> > customers, followed within a year or so by liquidation of the company.
> >
> > Why did the company not simply go back to using the Perl script ?
> >  I'm not
> > sure, but it was probably because the venture capital backers
> insisted on
> > the "universal data mapper".
> >
> > There were other factors, but the "universal data mapper" was a key one.
> >
> >                                  Cheers,   -- Adrian
> >
> >
> >
> >                                             INTERNET BUSINESS LOGIC
> >
>                                               www.reengineeringllc.com
> >
> > Dr. Adrian Walker
> > Reengineering LLC
> > PO Box 1412
> > Bristol
> > CT 06011-1412 USA
> >
> > Phone: USA 860 583 9677
> > Cell:    USA  860 830 2085
> > Fax:    USA  860 314 1029
> >
> > For more information about AM, visit the Agile Modeling Home Page
> > at www.agilemodeling.com
> >
> >
> >
> >
> >
> >
> >
> >
>
> For more information about AM, visit the Agile Modeling Home Page
> at www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------