A. L. wrote:

>>Z tego co kojarzę, częściej stosuje się spisane zasady w firmach dużych,
>>niż w firmach małych. I jakoś tak zwykle się dzieje, że firma gdy już
>>stanie się dużą, traci umiejętność samodzielnego tworzenia dobrych
>>produktów. Myślisz, że to przypadek? Bo ja uważam, że jest to WYNIK zbyt
>>szczegółowego regulowania zasad w firmie - w tym zasad tworzenia
>>oprogramowania. Patrząc np. na liczbę zatrudnionych w wielkich
>>korporacjach tworzących oprogramowanie, wydawać by się mogło że powinni
>>tworzyć na prawdę mnóstwo świetnych produktów. Tymczasem dobre produkty
>>pozyskują zwykle poprzez wykupienie małej firmy, a nie samodzielne
>>zrobienie.
>
> Z czalym szacunkiem, bzdura. Gdy zaczynalem pracowac w firmia, miala
> ona 20 osob, a "flagship product" mial pol miliona linii kodu. Kazdy
> programowal jak chcial.
>
> Dzisiaj firma ma 2000 osob a kod cos kolo 50 milionow linii.

Kiedy wprowadzono te reguły?
Chodzi mi o to, czy w momencie największego rozrostu firmy reguły już
obowiązywały, czy nie?

> Gdyby te
> 50 milionow linii bylo napisane jak kto chce, bylby totalny burdel.
> Zasada jest taka ze kod ma byc napisany tak, aby w przypadku
> znikniecia autora, kazdy inny programista mogl przejac prace "z
> marszu". Z reguly tez, inne osoby sa zaangazowane w utrzymanie kodu
> (maintenace) niz te osoby ktore ow kod napisaly.

Tak mnie też jeszcze zaciekawiło: dlaczego aż tak wzrosła liczba linii kodu?
Czy aż tyle nowej funkcjonalności doszło, czy konieczność zachowywania
wstecznej zgodności, czy po prostu pomimo stosowania reguł było tak, że
różne grupy tworzyły fragmenty zawierające prawie to samo - i bardziej
opłaciło się stworzyć drugi raz to samo, niż tracić czas na uwspólnianie
fragmentów z inną grupą?

do góry

>
> Nie ma zadnej sensacji. Nierozmawia sie o tym w kawiarniach. Znacznei
> wieksza sensacje zrobil MIT
>

A co takiego zrobili w MIT ?

do góry

Andrzej Jarzabek wrote:

>> Z tego co kojarzę, częściej stosuje się spisane zasady w firmach dużych,
>> niż w firmach małych.
>
> A skąd niby to kojarzysz?

Z opowieści.

> Robiłeś jakieś badania? Masz doświadczenie z
> setek małych i dużych firm?

Nie.

> Czytałeś jakieś artykuły na ten temat?

Być może, chociaż w tej chwili żadnego nie pamiętam.

> 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ń.

>> I jakoś tak zwykle się dzieje, że firma gdy już stanie się
>> dużą, traci umiejętność samodzielnego tworzenia dobrych produktów.
>> Myślisz, że to przypadek?
>
> Myślę, że to nieprawda. Skąd masz takie informacje?

Z różnych informacji w iternecie, gdzie stosunkowo często się trafia, że
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.

> 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.

> 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).

> Z drugiej strony z małymi firmami jest tak, że bardzo wiele nigdy nie
> dochodzi do etapu, gdzie mają "shippable" produkt, a w wielu przypadkach
> te ich produkty, które zostają wydane lub oddane klientowi są niskiej
> jakości. Tylko że w większości o nich nie słyszysz, bo takie firmy nie
> stają się duże, a raczej bankrutują.

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.

> 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.
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ą.

do góry

On Sun, 17 Apr 2011 14:39:25 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

>
>Kiedy wprowadzono te reguły?
>Chodzi mi o to, czy w momencie największego rozrostu firmy reguły już
>obowiązywały, czy nie?
>

Zaczeto wprowadzac reguly gdy firma miala okolo 100 osob.

>> Gdyby te
>> 50 milionow linii bylo napisane jak kto chce, bylby totalny burdel.
>> Zasada jest taka ze kod ma byc napisany tak, aby w przypadku
>> znikniecia autora, kazdy inny programista mogl przejac prace "z
>> marszu". Z reguly tez, inne osoby sa zaangazowane w utrzymanie kodu
>> (maintenace) niz te osoby ktore ow kod napisaly.
>
>Tak mnie też jeszcze zaciekawiło: dlaczego aż tak wzrosła liczba linii kodu?
>Czy aż tyle nowej funkcjonalności doszło, czy konieczność zachowywania
>wstecznej zgodności, czy po prostu pomimo stosowania reguł było tak, że
>różne grupy tworzyły fragmenty zawierające prawie to samo - i bardziej
>opłaciło się stworzyć drugi raz to samo, niż tracić czas na uwspólnianie
>fragmentów z inną grupą?

Dlatego ze wzrosla liczba produktow i ich zlozonosc.

A.L.

do góry

On Sat, 16 Apr 2011 19:45:42 +0000 (UTC), " "
<k...@g...SKASUJ-TO.pl> wrote:
> pisanie wszystkiego w szablonach (templates), nawet jesli
> nie daje to zadnego zysku nad zwyczajnym polimorfizmem
> przez dziedziczenie i funkcje wirtualne (a koszt jest: czas
> budowania kodu, slimaczenie sie debuggera na fafnastu klasach

Jaki debugger ci się ślimaczył? Ja nigdy nie zauważyłem, żeby na
szablonach jakiś działał wolniej, niż na normalnym kodzie.

Ja sam głównie zauważyłem takie problemy, że czas kompilacji potrafi
się wydłużyć, i że komunikaty o błędach bywają mało zrozumiałe.

Z drugiej strony jednak szablony, jeśli się da je zastosować, oferują
jednak często różne korzyści ponad to, co daje OO z funkcjami
wirtualnymi. Performance, to jedna sprawa, ale to nie zawsze jest
istotne. Często natomiast ważna jest możliwość kontroli pewnych
rzeczy na etapie kompilacji, gdzie polimorfizm w stylu OO pozwalałby
sprawdzać je dopiero w runtime.

do góry

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.

do góry

Andrzej Jarzabek wrote:

> 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";

Zachowaj choć trochę realizmu. Nawet programy do wykonywania pojedynczych
czynności, jak np. te zebrane w "util-linux" trochę linii jednak mają. Chyba
że uważasz, że nawet to autorzy koniecznie powinni to przepisać w stylu
bardziej OO, dzięki czemu wszyscy użytkownicy zyskają...

> 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

Tego, że w firmie, która uparła się na OO nie przekonam do jej porzucenia,
to zdaję sobie sprawę. Będę wybierał takie, gdzie OO nie jest obowiązkowe.

Gdy różnica w poglądach między jedną a drugą osobą w dyskusji jest zbyt
drastyczna, o przekonaniu którejś ze stron nie może być mowy.

Swoją drogą... gdy w firmie, w której pracuję czasem rozpocznę tego typu
filozoficzną dyskusję, to też w wielu przypadkach ludzie się ze mną nie
zgadzają. Natomiast gdy zastosuję w praktyce to o czym mówię - są zadowoleni
z efektu.

> ale przede wszystkim raczej
> w ogóle nie zostanie zatrudniony w takiej firmie,

Słusznie. Nie ma sensu nawiązywać współpracy na siłę.

Muszę już wyłamać się z tej dyskusji, bo przez to w ostatnich dniach trochę
za dużo przesiedziałem przed komputerem, ale jeśli pojawi się jakaś
wypowiedź dla mnie bardzo interesująca, to pewnie odpowiem.

do góry

On 17/04/2011 20:34, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> 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";
>
> Zachowaj choć trochę realizmu. Nawet programy do wykonywania pojedynczych
> czynności, jak np. te zebrane w "util-linux" trochę linii jednak mają. Chyba
> że uważasz, że nawet to autorzy koniecznie powinni to przepisać w stylu
> bardziej OO, dzięki czemu wszyscy użytkownicy zyskają...

Mówiłem przy podejmowaniu decyzji przy pisaniu nowego programu. W
przypadku legacy sytuacja jest zupełnie inna: po pierwsze masz gotowy
program, który działa, błędy w nim były eliminowane przez ileś lat i
jakby go pisać od nowa, to trzebaby ponieść jakieśtam koszta i poświęcić
czas tylko po to, żeby doprowadzić go do stanu, w którym teraz już go
masz. Druga zespół, który pisał program, zna funkcjonalność, dziedzinę
itd., a niekoniecznie zna OO czy jakieś tam inne techniki, które by było
sensownie zastosować. To jest historia stara jak świat.

Oczywiście te 20 linii nie trzeba koniecznie traktować dosłownie sam
napisałem niedawno skrypt w Perlu który miał pewnie ze 200 linii i nie
było w nim sensu stosować OO.

>> 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
>
> Tego, że w firmie, która uparła się na OO nie przekonam do jej porzucenia,
> to zdaję sobie sprawę. Będę wybierał takie, gdzie OO nie jest obowiązkowe.
>
> Gdy różnica w poglądach między jedną a drugą osobą w dyskusji jest zbyt
> drastyczna, o przekonaniu którejś ze stron nie może być mowy.

Nie wypowiadam się akurat o twoim przypadku, bo nie znam konkretów i
może jesteś wyjątkiem, ale w abstrakcyjnym przypadku kogoś, kto może się
czegoś nauczyć lub nie nauczyć żeby pracować jako programista, jest taki
problem:
1. Ktoś nie znający dobrych praktyk inżynierii oprogramowania w ogóle, a
OO w szczególności ma na dzień dobry bardzo ograniczony wybór tego,
gdzie go będą chcieli przyjąć do pracy.
2. Jeśli zatrudni się w firmie nie stosującej dobrych praktyk, to ta
firma będzie miała niskie przychody, więc raczej może liczyć na słabe
zarobki i/lub warunki pracy.
3. Firma ta w końcu zapewne zbankrutuje, a nasz programista straci pracę.
4. W końcu szukając kolejnej pracy rozbije się o problem, że firma miała
złą reputację z powodu niskiej jakości swoich produktów, i lata
przepracowane w tej firmie i wpisane w CV nie będą działać tak bardzo na
korzyść naszego programisty.

To są oczywiście ogólne prawidłowości, od których naturalnie są wyjątki,
ale lepiej mieć lepsze szanse, niż gorsze, nie?

do góry

On Sun, 17 Apr 2011 21:56:42 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>
>To są oczywiście ogólne prawidłowości, od których naturalnie są wyjątki,
>ale lepiej mieć lepsze szanse, niż gorsze, nie?

Panowie, czy mozna wiedziec jakie jest Panow doswiadczenie
PRZEMYSLOWE?... Bo poki co, wyglada mi ze wypowiadacie sie Panowie
moca teoretycznej wszechwiedzy. Podpierajac sie dosyc kiepska teoria

A.L.

do góry

A. L. wrote:

> Panowie, czy mozna wiedziec jakie jest Panow doswiadczenie
> PRZEMYSLOWE?... Bo poki co, wyglada mi ze wypowiadacie sie Panowie
> moca teoretycznej wszechwiedzy. Podpierajac sie dosyc kiepska teoria

W dużym skrócie:
Około 5 lat w czymś, co można by zakwalifikować jako embedded, chociaż
składa się z x86 działającego na Linuksie. Współtworzenie na to
oprogramowania, integracja oprogramowania naszego, oraz użytecznego dla nas
istniejącego open-source, także jeżdżenie w ramach serwisu w celu
diagnozowania/usuwania awarii. Wybierałem/przygotowywałem także mechanizmy
wymiany danych między tymi urządzeniami a serwerem.

Wcześniej w sumie ok. półtora roku tworzenia różnej drobnicy, dla której
trudno znaleźć jakiś wspólny opis.

do góry