On 17/04/2011 13:59, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> A skąd niby to kojarzysz?
>
> Z opowieści.
[...]
> Być może, chociaż w tej chwili żadnego nie pamiętam.
[...]
> Z różnych informacji w iternecie, gdzie stosunkowo często się trafia, że
[...]

No więc moja odpowiedź jest taka, że Twoje źródła informacji są bardzo
selektywne, więc nic dziwnego, że wyciągasz z nich fałszywe wnioski.

> duża firma X przejęła małą firmę Y posiadającą jakiś tam produkt,
> natomiast bardzo ciężko znaleźć informację, aby ta firma sama coś
> nowego zrobiła. Niech za przykład służą firmy Microsoft, Oracle i IBM.

Po pierwsze, tak jak pisałem, duże firmy, które przejmują małe firmy,
wybierają bardzo niewielki ułamek ogólnego produktu małych firm, który
akurat rokuje jakąś nadzieję na sukces. O małej firmie, która
wyprodukowała coś, czym się nie zainteresował pies z kulawą nogą, w
związku z czym wkrótce zbankrutowała, nie czytasz w internecie, bo to
jest non-news, ale tak właśnie wygląda historia ogromnej większości
małych firm.

Po drugie to, co piszesz o dużych firmach ma tylko sens wtedy, kiedy nie
uznajesz za "coś nowego" nowej wersji istniejącego produktu. W
rzeczywistości kolejne wersje zawierają wiele nowych features'ów, które
wymagają nie mniej inwencji przy tworzeniu niż nowe projekty.

Poza tym to również nieprawda, że wymienione firmy nie tworzą nowych
produktów. Np. Microsoft stworzył platformę .NET, język C#, Zune, XBox
(360), Kinect, Windows Phone 7. IBM stworzył przecież Watsona - ten
program, który wygrał teleturniej Jeopardy!, a wcześniej komputer
szachowy Big Blue razem z oprogramowaniem. Oprócz tego zrobili choćby
ileśtam programów w pakiecie Websphere.

>> Poza tym ja nic nie mówiłem o tym, czy te zasady mają być _spisane_ czy
>> nie. Być może tak jest, że przy pięciu programistach potrzeba spisywania
>> zasad jest mniejsza.
>
> To czy spisane czy nie, to mało istotne. Chodzi o to, na ile ograniczają
> inwencję pracownika. Gdy ktoś ma zapędy do ograniczania, zwykle znajdzie i
> czas na spisanie tych ograniczeń.

Znowu problem ograniczonej widoczności. W małych firmach te reguły
również często istnieją, nawet jeśli nie są spisane. Zresztą nawet w
dużych firmach często jest tak, że te zasady, które nie są specyficzne
dla danej firmy czy projektu, tylko należą do ogólnie uznanego zestawu
dobrych praktyk inżynierii oprogramowania, też nie są spisane, tylko po
prostu nie zatrudnia się ludzi, którzy ich nie znają lub nie potrafią
stosować.

>> Z drugiej strony takie firmy mają i tak permanentny brak
>> mocy przerobowych do rozwijania produktów, które już sprzedają.
>
> Nie znam na pamięć danych liczbowych, ile która firma zatrudnia pracowników,
> ale przy tej ilości powinni sobie radzić. Szczególnie gdyby było prawdą to,
> co twierdzisz - że z ustalonymi regułami programy tworzy się szybciej i
> łatwiej utrzymuje.

Widzisz, duże firmy tym się różnią od startupów, że mają już klientów
dla swoich istniejących produktów, którzy to klienci są skłonni płacić
konkretne pieniądze za dodanie do produktów nowych features, których
potrzebują. Do tego dochodzą zobowiązania wynikające np. z usuwania
błędów albo dostarczania obowiązkowych upgrades, plus możliwość
potencjalni klienci, którzy nabędą produkt pod warunkiem uzupełnienia go
o żądaną funkcjonalność. Jeśli firma odnosi jakiekolwiek sukcesy, to tej
pracy jest wystarczająco dużo, żeby nie tylko zająć całe obecne zasoby,
ale też wnieść konieczność zatrudnienia dodatkowych pracowników.

Z kolei te wszystkie wielkie liczby zatrudnionych pracowników pobierają
cały czas płace plus wnoszą dodatkowe koszty utrzymania stanowisk pracy
(choćby koszt wynajmowania powierzchni buirowej), niezależnie ood tego,
czy to, co robią, przynosi zyski, czy nie. Jeśli taki pracownik nie
zarabia na siebie, to firma jest stratna. Nawet jeśli jest nadwyżka mocy
przerobowych, to bardziej opłacalne może być zwolnienie nadmiarowych
pracowników, niż ponoszenie ryzyka tworzenia nowych produktów.

Ostatecznie sprowadza się to do tego, że rozwijanie istniejących
produktów często jest bardziej opłacalne, niż tworzenie nowych.

>> Co
>> oczywiście nie znaczy, że to się nie zdarza, choćby Google jest przecież
>> taką firmą, która regularnie wypuszcza nowe produkty generalnie niezłej
>> jakości.
>
> Co do jakości produktów Google istotnie nie mam zastrzeżeń. Uważam ich za
> wyjątek (jakie panują tam reguły - nie mam pojęcia).

Nie tak trudno się dowiedzieć, jeśli cię to naprawdę interesuje. Na
początek powiem tyle, że owszem, używają technik OO do prawie wszystkiego.

> Jak najbardziej tak jest, że jedne firmy okażą się świetne, drugie
> beznadziejne. Natomiast jeśli spróbuje się ustawić sztywne reguły,
> zabraniając pracownikom własnej inwencji, firma zawsze będzie co najwyżej
> przeciętna.

Uwaga na nisko przelatujące kwantyfikatory. Być może jest tak, jak
mówisz, jeśli reguły zakazują _wszelkiej_ inwencji. Natomiast w ramach
powiedzmy narzucenia OO jest nadal wiele miejsca na inwencję pracownika.
Natomiast narzucenie reguł ograniczających _niektóre_ formy inwencji nie
tylko nie przeszkadza w osiągnięciu sukcesu, ale wręcz dla instucji
powyżej pewnej wielkości (powiedzmy więcej niż 2-5 programistów) jest
dla tego sukcesu praktycznie konieczne.

Co więcej, te reguły nie działają przecież z automatu. To nie jest tak,
że jeśli reguły kodowania w danej firmie mówią że ma być stosowane OO,
to nie ma możliwości zastosowania czego innego gdziekolwiek. Jeśli
pracownik uważa, że do zaimplementowania danego kawałka produktu lepiej
nada się np. język funkcyjny albo Prolog, to zwykle ma możliwość
przedstawienia swoich racji i przekonania do nich przełożonych. Tylko
żeby to dobrze zrobić, musi dobrze rozumieć OO, jego słabe i mocne
strony i potrafić uzasadnić korzyści wynikające z użycia alternatywnych
technik.

Przy czym dla podejścia strukturalnego/proceduralnego z punktu widzenia
inżynierskiego takie sytuacje w zasadzie wyczerpuje scenariusz "program
ma mniej niż 20 linii kodu"; i rzeczywiście - nawet w firmach, gdzie
nromalnie pisze się obiektowo, wolno proceduralnie-strukturalnie pisać
proste skrypty w shellu, Perlu czy innym TCL-u.

Ktoś, kto myśli, że obiektowość - w stosunku do programowania
strukturalnego - zaciemnia intencje, utrudnia modyfikacje programu,
spowalnia początkowy development, że to przerost formy nad treścią i
różne inne "mądrości" wyrażone w tym temacie w tym wątku, nie tylko
nigdy nikogo nie przekona w żadnej sensownej firmie stosującej OO, nie
tylko nie zauważy rzeczywistych przypadków, kiedy odrzucenie
istniejących coding standards jest sensowne, ale przede wszystkim raczej
w ogóle nie zostanie zatrudniony w takiej firmie, a jeśli nawet
zostanie, to szybko z niej wyleci.

>> Te, które zostają wykupione przez
>> duże firmy to 0.01% ogółu, który zostają wybrane dlatego, że pozostałe
>> 99.99% to krap.
>
> Zbyt daleko idące uogólnienie.

I kto to mówi.

> Są nisze, którymi duże firmy się nie interesują. Na tyle małe, że działająca
> w nich mała firma nigdy nie staje się wielką.

Ale w tych firmach też obowiązuje prawo Sturgeona.