On 2011-07-14, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2011-07-14 15:46, Stachu 'Dozzie' K. wrote:
>> Warianty postępowania:
>> 1) udało ci się zdebuggować problem; odrzucasz reklamację jako
>> bezpodstawną
>> 2) udało ci się zdebuggować problem; wykonujesz naprawę (obejście)
>> w swojej aplikacji
>
> Utopia. Komu by się chciało szukać buga który przychodzi od klienta z
> Somalii "bo jak tu klikam to mi się psuje" i jest gluchy na próby
> wyciągnięcia lepszego opisu. Tu nawet nie ma co debugować. Nagle trzeba
> zwracać kasę.

Ale wiesz że to nie tak działa? Nigdy nie słyszałeś o odrzuceniu
zgłoszenia reklamacyjnego z powodu niedostatecznego opisu usterki?

>> Jeśli przewidujesz dużo awarii
>> w swoim programie, to należy zmienić metodologię wytwarzania
>> oprogramowania, architekturę programu, język programowania -- jedno
>> z powyższych albo wiele naraz.
>
> I to wszystko przy zerowych kosztach. Pstryka się palcami i już.

Oczywiście że nie. Ale widzisz, to już twoja wina że wybrałeś błędogenne
narzędzia do wyprodukowania swojego softu.

I to wcale nie jest dobrze że tak wybrałeś, bo produkujesz z błędami,
których dałoby się uniknąć.

>> o to się w tym wątku bijemy: zmienić
>> któryś element wytwarzania oprogramowania (wymienione w poprzednim
>> akapicie), żeby ryzyko zajścia awarii/błędu -- a co za tym idzie, ryzyko
>> poniesienia kosztu obsługi zgłoszenia reklamacyjnego -- było niskie.
>
> Jest cała masa metod, technik, sztuczek. Pracują nad tym całe
> korporacje, naukowcy i pryszczate nastolatki szukając jak najlepszych
> metod pisania softu bez bugów. I nagle ktoś rzuca haslem "gwarancja" i
> ich bazy bugów topnieją w oczach, soft się przepisuje do nowego
> zajebistego języka, ludzie ucza się nowych metodologii. A potem się budzisz.

A teraz poproszę argument merytoryczny, chyba że ci takiego brakuje.

--
Secunia non olet.
Stanislaw Klekot