Subject: Re: gdb
From: "Leonard H. Tower Jr." <tower@ai.mit.edu>
Date: Sat, 13 Dec 1997 09:52:07 -0500 (EST)

   Date: Sat, 13 Dec 1997 01:41:56 -0800
   From: Chris Maeda <cmaeda@alum.mit.edu>
   
   We use
   
   Visual J++, Visual Cafe --- Java IDE's with GUI builders
   Visual Quantify --- essentially a java gprof with a GUI 
   ER/Studio --- graphical data modelling tool
   Oracle, SQL Server --- gdbm? yeah, right
   Silk Test, QA Partner --- GUI regression testing tools
   JavaScope --- test coverage analyzer
   Star Team --- integrated SCM and bug tracking
   MS Project, MS Team Manager --- project scheduling and tracking
   
   None of these tools are available as free software and we wouldn't
   use them if they were.  The economics of software have changed 
   in the last few years.  Programmers are now too expensive and tools
   are far too complex to have your people dicking around with the
   source to their tools instead of doing real work.  The per seat
   cost of all of these tools put together is less than 1 month's salary 
   for an experienced programmer.
   
Chris:

How reliable are these tools?

How many mnoths of experienced programmer time have you lost to bugs
and workarounds?  Is communication with the programmers good enough,
that you're sure?  Many programmers put up with quirks and never truly
realise how much time they are wasting working around them.

How responsive are the vendors to fixing the tools?

I remark that if a company has it's programmers "dicking around with
the source to their tools" (chris' language) they are in trouble -
their staff is out of control.  A company should only fix a bug or
improve a tool for good reason.  Either they see an economic
advantage, usually improved productivity, or they wish to make a
contribution to the free software community.  And it's usually best to
only have one or a few programmers do the work on the tools - the rest
should be working on product.

best -len