On 21/07/2013 10:54, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksfevv$9th$...@s...invalid...
>
>> Może nie być nieco drożej, tylko dużo, dużo drożej. Niektórzy dostawcy
>> w ogóle się na to nie zgodzą, bo do budowania systemów używają
>> istniejącego wcześniej kodu, który jest objęty tajemnicą handlową.
>
> No popatrz - cały Linux jest open source - i jak najbardziej nadaje się
> do wielu rzeczy, choć przecież jest darmowy.

Nie rozumiem jaką w związku z tym masz tezę? Że można używać Linuxa jako
systemu CRM, księgowości czy payroll?

> Więc dywagacje "drożej-taniej" są równie dobre jak wróżenie z fusów. Czy
> 10x tyle to drożej? A czy lepiej kupić coś, co posłuży 10 lat, czy
> system na 1 rok? Możemy gdybać, możemy snuć różnego rodzaju domysły...
> ale bez konkretów to do sensownych wniosków nie dojdziemy.

Powiem w ten sposób - mam wiele lat przepracowanych w dużych firmach (a
więc takich, które ewentualnie można pozwać na te miliony i mieć
nadzieję je dostać) robiące oprogramowanie dla dużych firm (które stać
na zakup oprogramowania za miliony). I te firmy nie oferowały klientom
kodu źródłowego swoich produktów.

>> z nich. Ponadto w ogóle zrozumienie architektury systemu na podstawie
>> kodu źródłowego jest niebanalnym zadaniem jeśli nie masz do dyspozycji
>
> Dlaczego jedynie "kodu źródłowego"? Jest dokumentacja,

O ile jest, znaczy pewnie jest 'end user documentation' do programu, ale
czy jest dokumentacja opisująca architekturę systemu i projekt kodu to
osobna kwestia. A nawet jeśli jest, bo taka dokumentacja jest wymogiem
umowy, to kolejne pytanie ile taka dokumentacja jest warta w momencie
kiedy przygotowuje ją ktoś, komu aktywnie zależy na tym, żeby jak
najtrudniej było z niej skorzystać.

> kod źródłowy też
> nie śmieciowy, ale spełniający określone standardy itd.

Jakie standardy? Nic mi nie wiadomo o jakichkolwiek standardach, które
by można zadekretować umową, a które gwarantowałyby nieśmieciowość kodu.

> Oczywiście,
> wymaga to wszystko IQ rzędu 130 i być może znajomości jakiegoś języka
> programowania, ale to nie są wyśrubowane wymagania w XXI wieku.

Kilka razy spotkałem się z sytuacją konieczności rozczytania kodu i
wprowadzenia zmian do komponentów, na których nikt się nie znał, bo ten,
co je robił odszedł z firmy, a nikt inny ich nie ruszał od dłuższego
czasu. Na podstawiee tych obserwacji uważam, że jest to trudne,
czasochłonne, kosztowne i ryzykowne - efektywne zapoznanie się z cudzym
kodem bez możliwości konsultowania się z autorem to wysiłek porównywalny
z napisaniem tego kodu od początku. Nie mówię nawet, że dla mnie, bo ja
zapewne mam niskie IQ (nie mierzyłem, to nie wiem), ale moim
niewątpliwie inteligentnym kolegom również sprawiało to problemy.

> Odwrotnie - zgadzanie się na closed source i nie wnikanie "co jest w
> środku" prowadzi do uzależnienia od określonej zewnętrznej firmy. Jeżeli
> ta firma opiera się na jakimś geniuszu, który akurat postanowił sobie
> umrzeć, to wali się wszystko niczym klocki domina. Takie rzeczy były już
> przerabiane przez branżę.

Naprawdę? Gdzie/kiedy?

Oczywiście że oferowanie kodu źródłowego redukuje ryzyko klienta, ale
też zwiększa ryzyko dostawcy. Dlatego distawcy się albo nie zgadzają,
albo proponują wyższe ceny.

Weź więc pod uwagę w naszym scenariuszu, że masz nieprzekraczalny budżet
na system w kwocie czterech milionów. I masz jednego dostawcę, który
oferuje umowę na system bez źródeł za dwa miliony, i drugiego, który
daje źródła, ale za cztery miliony. Którego wybierzesz? Przecież jeśli
się okaże, że system wymaga zmian w specyfikacji, żeby go wdrożyć, to co
z tego, że będziesz mógł poszukać innego dostawcy które ci te zmiany
zaimplementuje, skoro już nie będziesz miał czym zapłacić? A nawet jak
ci jeszcze rtrochę zostanie, to nikt ci niezrobi tej modyfikacji za
grosze, bo wejście w cudzy codebase to duża inwestycja upfront.

>> wytłumaczyć. W szczególności jeśli wykonawcy zupełnie nie zależy, żeby
>> zdawany przez nich system był łatwy do zrozumienia przez kogokolwiek
>
> Takich wykonawców eliminuje się już na początku.

Na jakiej podstawie?

> Wykonawcy musi zależeć

A skąd wiesz, komu zależy? Do umowy przecież tego nie wpiszesz.

> i musi trzymać się standardów,

Jakich standardów?

> a to co robi musi być "łatwe do zrozumienia" przynajmniej przez fachowców.

Wpiszesz do umowy, że dostarczony kod ma być "łatwy do zrozumienia"?

>> Rewidowanie, czytanie, konsultowanie takiej specyfikacji ciężko jest
>> tak zrobić, żeby wyłapać wszystkie czy nawet większość takich błędów.
>> Dalsze
>
> Ba! Życie to ciężkie jest, a życie programisty szczególnie: nie każdy
> może pić drinki z palemką jak AL czy Knuth.

Nie rozumiem w jaki sposób taka konstatacja niweluje fakt, że wiele
specyfikacji zawiera błędy.

>> Drugi powód jest taki, że język naturalny nie jest wystarczająco
>> precyzyjny, żeby jednoznacznie opisać takie wymagania. W tekście pisanym
>
> Jeżeli - jako programista - nie potrafisz opisać wymagań - to nie
> potrafisz - także jako programista - napisać programu. ;)

Przecież gdyby zamawiający miał na etacie programistów potrafiących
napisać ten program, to by go w ogóle nie zamawiał, tylko kazał im napisać.

>> według umowy, to sobie spokojnie zbankrutuję, stracę tego laptopa co
>> go mam na majątku firmy, a z oszczędności zakupię kolejnego laptopa i
>> użyję go jako kapitału założycielskiego kolejnej spółki z oo.
>
> Zbankrutujesz... zdarza się. Ale twoja wiarygodność jako partnera w
> biznesie będzie równa zero, jeżeli nie ujemna. Dlatego na tym laptopie
> będziesz mógł ewentualnie pograć w Sapera.

E tam. Ludzie bankrutują, potem zakładają kolejne biznesy i jakoś
działają, często z większym powodzeniem niż poprzednio.

>> stratami. Może np. być tak, że złe położenie przycisku powoduje, że co
>> jakiś czas operator wciska nie ten przycisk i powoduje mniejsze lub
>> większe straty - nie wiadomo jakie, ale można oszacować
>> prawdopodobieństwo, że będą np. w przedziale 100-150 tys. I kwestia jest
>
> To po co się przejmować? Koszt wprowadzenia poprawki to 250 000 euro,
> bez poprawki straty wynoszą 150 000 euro.

Oczekiwane straty wynoszą 150 000 euro, na podstawie bardzo niepewnych
przesłanek. W rzeczywistości mogą być dużo wyższe.

> Nie wprowadzenie poprawki daje
> +100 000 euro. Wprowadzenie poprawki daje -100 000 euro oraz brak
> pewności, że to przyniesie spodziewane rezultaty i zakończy się
> wydatkiem jedynie tych 100 000 euro. Właśnie odkryliśmy czym jest
> konserwatyzm liberalny.

Przejmować się możesz tym, że decyzja o wydaniu dwóch milionów na syetm
oparta była na szacowanych zyskach czy oszczędnościach z użycia tego
systemu, wysokości powiedzmy pół miliona rocznie. To, że źle umieszczony
przycisk generuje rocznie 100 tysięcy strat powoduje, że korzyści z
oprogramowania są niższe niż oczekiwane. Znajdź cztery podobne problemy
i okaże się, że system za dwa miliony przynosi tyle samo strat, co
korzyści - równie dobrze możnabyuło tymi dwoma milionami napalić w piecu.

Co gorsza, ponieważ mówimy nie o pewnych zdarzeniach, tylko o ryzyku, to
może być tak, że wymieniasz pewny i stały koszt na ruletkę. Regularne
tracenie 100 tysięcy rocznie obniża twoją rentowność, ale można
przewidzieć i zarządzać firmą tak, żeby działała mimo tego. Losowy
problem narażający cię na losowe straty o wartości oczekiwanej 100
tysięcy może działać tak, że w pierwszym roku nie będzie żadnych strat,
w drugim żadnych, a w trzecim będzie pięć milionów, przez co firma
zbankrutuje i cała zabawa się zakończy.

W kmońcu problem klienta jest taki, że to, że cena zmiany wynosi 250
tysięcy, i wynikające z tego straty 100 tysięcy rocznie, są konsekwencją
złych wyborów samego zamawiającego, a w szczególności błędnego
przekonania, że kontrakt fixed price fixed scope jest dla niego
korzystniejszy.