On 2011-07-14, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2011-07-14 22:44, Stachu 'Dozzie' K. wrote:
>>> Czekaj, a kto decyduje o tym jaki jest niedostateczny?
>> A w innych branżach? Jeśli się nie dogada sprzedający i kupujący,
>> zostaje zaufana strona trzecia (np. sąd konsumencki).
>
> I będzie analizował coredumpy lub bedzie miał ekspertow analizujących
> coredumpy?

Na tych samych warunkach jak ma ekspertów-szewców analizujących but albo
ekspertów-mechaników samochodowych.

Akurat nie trzeba być programistą żeby widzieć że klient nie podał
podstawowych informacji niezbędnych do diagnozowania problemu (na
przykład nie podał kiedy błąd występuje czy jak go odtworzyć), albo że
podał tyle ile było w jego możliwościach.

>>> Dla mnie b) jest niedostateczny bo gdzie są do cholery pozostałe
>>> rejestry i wersja zasilacza ?!?!? Reklamacja odrzucona!
>> I w tym momencie pewnie UOKiK czy inny rzecznik praw konsumenta nakłada
>> na ciebie karę, bo klient podał tyle, ile był w stanie.
>
> ROTFL. Klient zazwyczaj nie podaje wszystkiego. Klient to zazwyczaj
> idiota techniczny. Chcesz karać firmy za to że na podstawie pustych
> technicznie opisów problemu nie sa w stanie usunąć rzeczywistych albo
> wymyslonych problemów?

Na razie poważnym firmom się to udaje. Jeśli klient podał za mało
danych, wsparcie techniczne dopytuje się o pozostałe.

> Problem u klienta może być niepowtarzalny
> gdziekolwiek indziej. Wystarczy że klient ma nietypowy hardware,
> firewall, antywirus i twoj soft szlag trafia. Nie mozna tego
> przetestować we wszystkich warunkach i co gorsza nie można mieć
> identycznych środowisk jak klient bo jest ich za dużo.

I wtedy oddajesz klientowi pieniądze, skoro mu twój soft nie działa.
Niby z jakiej okazji klient ma płacić za twój soft, skoro nie jest
w stanie go używać?

>> Natomiast
>> odrzucenie a), jeśli to by był cały otrzymany opis, mogłoby być (choć
>> nie musiało) zasadne.
>
> *Kto* o tym decyduje co jest a co nie kompletne i zasadne?

Próbujesz stworzyć problem tam gdzie go nie ma, gdy się przejdzie do
innej branży, na przykład samochodowej.

>>>> Oczywiście że nie. Ale widzisz, to już twoja wina że wybrałeś błędogenne
>>>> narzędzia do wyprodukowania swojego softu.
>>> Powiedz to tym którzy piszą soft przez kilkanaście lat. Nie przepisują -
>>> piszą, dopisują i sprzedają *ciągle*. Powiedz że hello world można
>>> przepisać w kilka minut na pythona to może niech przepiszą te swoje
>>> prymitywne systemy finansowe nad ktorymi pracują 15 lat z
>>> C/COBOLA/Pascala na coś lepszego. Pstryk i już. Python jest przecież
>>> taki fajny.
>> Bzdurzysz, gościu. Zaperzyłeś się. Może idź i się uspokój najpierw?
>
> Czy ja wiem, widziałem juz kilku ludzi ze świetnymi radami co można by
> zrobić żeby było lepiej. Rady jak to rady - słuszne w koncepcjach
> podstawowych.

Tylko na razie wyjmujesz coraz bardziej wydumane przypadki jako
argumenty, podczas gdy w ogóle nie próbujesz obalić (ani w inny sposób
się odnieść) analogii z innymi branżami usługowo-przemysłowymi, które
zostały podane.

>> Jak ktoś produkuje system finansowy od 15 lat, to przez ten czas już
>> pewnie opracował standardy zapewniania jakości -- inaczej by się nie
>> utrzymał na rynku.
>
> I standardy te po 15 latach są dokladnie zbalansowane z potrzebami
> klienta. Włącznie z tym ze producent i klient wie o jakis-tam problemach
> które nie są krytyczne i można z nimi żyć.

Ale tylko dlatego że to branża finansowa, że soft przetwarza bardzo
ważne dane i może spowodować znaczne straty oraz że klient z producentem
ma starannie przygotowaną umowę. A my tu mówimy o możliwości odzyskania
pieniędzy przez Kowalskiego, który ma serdecznie w dupie czy to ATI się
opiera przed naprawieniem sterowników karty graficznej, czy to jednak CD
Projekt zjebał grę. Kowalskiemu Wiedźmin nie chodzi, więc Kowalskiemu ta
gra niepotrzebna, chce ją oddać i chce z powrotem wydane na nią
pieniądze. Pójdzie za nie na piwo.

>> Ale jeśli sprzedają mi (firmie w której pracuję)
>> system obiegu dokumentów, który nie wytrzymuje obciążenia *nastu nowych
>> dokumentów dziennie i wywołuje OOM-killera na maszynie z 8GB RAM-u, to
>> chyba mam prawo domagać się naprawy bądź zwrotu kosztów?
>
> Oczywiście, przecież nie kupileś tego na półce w warzywniaku. Kupileś
> ten system na umowę, a na pewno na niej zawarty jest support/serwis.
> Dzień jak co dzień.

No chyba że jednak ten system jest kupiony właśnie w "warzywniaku",
czyli w sklepie komputerowym. Czyli chcę moje pieniądze z powrotem.

>>>> I to wcale nie jest dobrze że tak wybrałeś, bo produkujesz z błędami,
>>>> których dałoby się uniknąć.
>>> Jasne. Właściwy język == zero błedów. Utopia.
>> A kto ci nakłamał że zero? O_o
>
> Twierdzisz że jakiś błedów mozna uniknąć w wyniku złego wyboru języka.
> Ale wybor nastapił 15 lat temu, był wtedy najlepszy a dzisiaj masz
> miliony lini kodu z czego 80% nie ma żadnej dokumentacji poza kodem.
> Oczywiście, teoretycznie to jest źle, ale praktycznie to codzienność. To
> *nie* jest pralka z dokumentacją na 30 stronach pojmowalną przez
> przeciętnego elektryka.

(W tym akapicie na potrzeby argumentacji zakładam że jesteś autorem
takiego piętnastoletniego systemu; nie ma to absolutnie związku z tym,
czy uważam że rzeczywiście masz coś takiego na koncie.)

Trudno. Za błędy młodości też trzeba czasem płacić. Ja doskonale
rozumiem że chcesz uniknąć odpowiedzialności za taki piętnastoletni
system, gdzie wprowadzenie jakiejś poprawki może się skończyć
tragicznie; też bym chciał będąc na twoim miejscu, bo to jak chodzenie
po polu minowym. Choć być może wypracowałeś przez te piętnaście lat
metody wyłapywania błędów, przez co twój program jednak ma dość wysoką,
wypróbowaną jakość; wtedy raczej zgłoszeń reklamacyjnych się nie musisz
obawiać, bo nie będą występować.

>> Dobór właściwego języka i właściwych narzędzi do niego pomaga
>> *zmniejszyć* ilość błędów, a nie zlikwidować je całkowicie.
>
> Dobór to sobie robisz *przed* a nie w trakcie. Niestety soft na rynku
> zazwyczaj jest w trakcie. Malo kto ma komfort zaczynania na nowo.

Trochę kiepski argument żeby się wymigać od podniesienia jakości
kiepskiego softu. Jeśli jest kiepski na tyle że producent się obawia
reklamacji, tzn. producent nie ma pewności że jego program będzie
działać, to znaczy że należy ten program przepisać tak, żeby pewność
dawał.

>> I naprawdę nie będę płakał, jeśli hipotetycznie twoja firma, która
>> umyślnie kładzie laskę na jakość (skoro uważa że jej soft jest tak
>> podatny na błędy, że obawia się roszczeń gwarancyjnych, a wybrała
>> narzędzia i proces produkcji tylko dlatego że tanie i szybkie), upadnie.
>> Powiedziałbym że rynek wręcz na tym zyska.
>
> Uff ciekawy wniosek. Niestety codzienność jest odmienna, ale to moje
> skromne obserwacje.

Aj, widzisz. Obserwacja codzienności wcale nie ma obowiązku się zgadzać
ze spekulacjami zakładającymi upadek rozważanej hipotetycznej firmy,
niezależnie od tego czego zgodność miałaby dotyczyć (bo nie rozumiem
do którego fragmentu się odnosi twój komentarz).

>>> Merytoryczny argument jest bardzo prosty: software zawsze zawiera błędy.
>>> *ZAWSZE*. Dzięki furtce typu "ojej, odrysowalo mi się w zlym kolorze,
>>> ide oddać do sklepu tylko dokończe ten projekt samolotu" producenci
>>> dostana po dupie.
>
>> Nie dostaną. Twoim zdaniem można zwrócić pralkę sprzedawcy, bo się nie
>> spodobał kolor drzwiczek albo diody na wyświetlaczu?
>
> Tak. Niektórzy sprzedawcy uważają to za istotny punkt przyciągający
> klientów. Niektórzy nie. Wolny rynek.

Ale sprzedawca nie ma obowiązku przyjąć takiego zwrotu. To jest istotne.

Ty jako dostawca softu nie masz (nie miałbyś) obowiązku przyjąć zwrotu
programu li tylko na podstawie niepodobającego się koloru menu.

> W zdaniu powyzej chodziło jednak o coś innego: *dowolna* wada
> oprogramowania może stac się podstawą gwarancji. Dowolna pierdoła.

Tylko musi to być wadą. A jeśli ta wada jest _pierdołą_, to na ogół da
się ją naprawić w parę chwil.

>> To dlaczego uważasz
>> że w oprogramowaniu nie byłoby zastosowania takiego terminu jak "istotna
>> wada, uniemożliwiająca lub utrudniająca używanie"?
>
> Nie działa przycisk do drukowania literek do gory nogami. To tylko
> promil promila funkckonalności ale mi utrudnia używanie bo mam taki
> kaprys. Poproszę o zwrot kasy lub usunięcie wady w 14 dni.
>
> Czy możesz powiedzieć kto będzie decydował o istotności wady?

"A był kiedyś taki przycisk? Nie było? To jaka to niby wada? Do widzenia
Panu."

--
Secunia non olet.
Stanislaw Klekot