erict@flatline.UUCP (j. eric townsend) (06/07/88)
In article <8013@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: > In article <1133@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > >And my notion of fixing a bug involves getting > >a fix to the person with the problem within a week. Not "in the next > >major release - and oh yes, that will cost you $2500[1]". I don't find this too unrealistic, but it seems very, very optimistic to expect a working solution. > The response would not necessarily include a "fix" for the problem, > although often we would promise fixes in the future and suggest interim > workarounds. Quite often the trouble reporter had not found an actual > software error, but rather had misinterpreted the specs, and the > response would include an explanation to help the reporter understand. Heh. When I worked for a small banking software firm, this was one of our favorite replies. Our customer support people, as they were, coddled the customer till us techies could come up with an answer. Luckily, we had written the the code in such a hurry, and so loosely, that we could either convince the user that it was: really a feature; unimportant, and wouldn't affect the rest of the program; that we could ship a patched version that afternoon (this was true most of the time[1]); or that it was EDS's fault :-). (Apologies to EDS employees, but hey...) [1]: Our program specs changed on a daily basis. Our product, its user interface, and large parts of the program were subject to change w/o any real notice to the *programmers*. The president would get a "brain fart" and tell us how we were supposed to do it now, and it had to be ready by tomorrow, because he'd already sold two. %90 of the time, he hadn't sold any, and he'd change his mind next week... :-) > Responsible software organizations do NOT install "quick fixes" in > existing systems (except in extreme emergencies), but rather analyze > the problem, design an integrated solution, assign competent staff > to implement the solution, merge it into the product, thoroughly test > not only the problem area but also the rest of the product operation, > update documentation as required, run the result through QA to the > distribution department. Naturally this expensive process cannot be HAHAHAHAHAHAHA... I guess that makes only really increadibly huge companies "responsible software organizations".. I've never understood how smaller companies could do the full QC required by common sense. Maybe someone could write an AI system to beta-test software/make it crash. Our pres would tell us to do it the above way, with "rethinking the solution as to benefit the product as a whole", and to "fully test our fix before submitting the fixed product to QC". Then he'd tell us to have it done in 3 days.... :-) Moral: If you don't have a degree, go to work for a screwy little company with only a small chance of success. You'll get to bunches of different neat things, write bunches of code (sometimes over and over again :-(, and then hang around for the slow death of the company while making a tidy sum to write the ultimate c-tree while they think you're writing the code you did last week... -- Know Future J. Eric Townsend ->uunet!nuchat!flatline!erict smail:511Parker#2,Hstn,Tx,77007 ..!bellcore!tness1!/
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/07/88)
In article <694@flatline.UUCP> erict@flatline.UUCP (j. eric townsend) writes: >HAHAHAHAHAHAHA... I guess that makes only really increadibly huge >companies "responsible software organizations".. I've never understood >how smaller companies could do the full QC required by common sense. For your information, the trouble reporting system I set up was at a small company, less than 100 employees and around 4 to 6 on the software development staff. And our company president was probably as flaky as yours. I don't see how we could have survived NOT doing an adequate job of customer support and quality control. This isn't the place to discuss business ethics, but basically if you do stupid things merely because management tells you to, you must not have much confidence in your competence. If there are genuinely good reasons for some course of action, explain it to your technical management. If they act truly irrationally, get a job elsewhere.