home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / programm / misc / 1354 < prev    next >
Encoding:
Text File  |  1992-08-16  |  3.4 KB  |  69 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!centerline!hroudland!cparker
  3. From: cparker@centerline.com (Charles Parker)
  4. Subject: Re: FLAME: BORLAND TECHNICAL SUPPORT
  5. Message-ID: <1992Aug16.202412.7830@centerline.com>
  6. Sender: news@centerline.com
  7. Nntp-Posting-Host: hroudland
  8. Reply-To: cparker@centerline.com
  9. Organization: CenterLine Software
  10. References: <BsqpJn.Enq@apollo.hp.com>
  11. Date: Sun, 16 Aug 1992 20:24:12 GMT
  12. Lines: 55
  13.  
  14. In article Enq@apollo.hp.com, nelson_p@apollo.hp.com (Peter Nelson) writes:
  15. >  Take a look at Michael Cusamano's research at MIT on US software 
  16. >  productivity.  He claims the Japanese are about to do to the soft-
  17. >  ware industry what they've already done in auto's, consumer electronics, 
  18. >  etc.  He has researched some pretty impressive numbers on their
  19. >  productivity and quality.  He claims that they employ a team programming
  20. >  approach which is far more effective than the "rugged individualist"
  21. >  philosophy that US programmers prefer.   
  22. >  
  23. >                            ----------------                                           I love these so-called "impressive numbers", since when has good software 
  24. been about "impressive numbers". When was the last time you used a japanese
  25. spreadsheet. I agree that developing software requires team players, but
  26. it also requires an individual creativity. Analogously, a software product 
  27. may be completely bug free, but is it any use? likewise, a product may crash
  28. every fourth time you use it, but still be extremely useful.
  29.  
  30. By the way, there is an american company which practices many of the same
  31. techniques as these japanese software factories, it's name is Microsoft.
  32. A good idea for you would be to switch over to the Microsoft C/C++ compiler
  33. and get a taste of a development environment with some really impressive 
  34. numbers.
  35.  
  36. >
  37. >  As you read the manuals and try things out, inevitably you
  38. >  will find things which do not work as you expected them to.   
  39. >
  40.  
  41. Borland's on-line help and printed documentation blow any other compiler
  42. vendor's, japanese or american, out of the water.
  43.  
  44. >  I'm a beginning Windows programmer, so I will naturally tend to assume
  45. >  there's a high likelihood that the problem is with me.  But I've also 
  46. >  had enough experience with PC software to know that there's a very good
  47. >  chance the problem is with them.    Since this discussion began, I've had
  48. >  to call Tech Support about 5 problems:   3 Borland, 1 Lotus, 1 Datastorm.
  49. >  Of these 1 Borland, 1 Datastorm, and 1 Lotus were *bugs in the product*.
  50. >  1 Borland was a "feature" of the IDE, and 1 Borland was a mistake on
  51. >  my part.   So I don't think my track record is that bad, and therefore
  52. >  I think my criticisms are legitimate. 
  53. >
  54.  
  55. If you want to waste your time with what are 60% of the time "legitimate"
  56. criticisms, go ahead. I would rather get my work done.
  57.  
  58. >  They could minimize a lot of their Tech Support costs by having more 
  59. >  reliable products in the first place!  This is not just because there
  60. >  would be fewer bugs to call about.  It's mainly because of the odds that 
  61. >  go into making the call-or-not-to-call decision:   If I know that only
  62. >  1 of the last 5 problems I had was due to an error on my part, and the
  63. >  others were shortcomings of the manufacturer then what should I assume
  64. >  about problem number 6?                                                
  65. >
  66. To the point, I would rather have Borland's IDE, even with a few GPF's 
  67. every once in a while, than anyone else's. 
  68.  
  69.