Znam podobny przypadek, gdy ktoś przygotował po godzinach UI ułatwiające konfigurację firmowej aplikacji.
Projekt do użytku wewnętrznego, dostępny tylko na firmowym repo.
Od razu po prezentacji pojawiły się głosy, że ktoś to będzie musiał utrzymywać, a autor może przecież odejść z firmy.
Z mojego punktu widzenia dość absurdalny argument, bo jeśli aplikacja faktycznie przyspieszy pracę, to zawsze można przydzielić wewnętrznego maintainera.
Robiłem w tym czasie research innego narzędzia i widząc te reakcje stwierdziłem, że chyba nie warto się tym zajmować.
Myślałem, że zawsze tworzy się pełno wewnętrznych narzędzi do pracy. Tak jak prototypów. Zazwyczaj nie mają długiego cyklu życia, bo ktoś może wpaść na lepszy pomysł. Dawniej w czasach VB to chyba było normalne. Chciałbym poznać wyniki badań nad wydajnością programowania w EU. Bo wydaje się, że po 30 latach robienie takich narzędzi powinno być o wiele wydajniejsze. Nawet sam opracowałem coś szybszego do robienia UI niż VB.
To jest tylko moje anecdata, ale wydajność pracy we wszystkich polskich projektach w których uczestniczyłem była wielokrotnie wyższa od europejskich.
Problemem jest ociężały proces i biurokracja.
Mi się wydawało, że wiele wynika z tego czy jest kultura minimalizacji kosztów za wszelką cenę, czy utrzymywania (tak jak rodziny) zespołu wykwalifikowanych ludzi. Bo jeśli ta pierwsza kultura przenika do pracowników, to oni walczą o koszty, mimo że nie są beneficjentami zysków.
Dziwi mnie też strach przed utrzymywaniem. Czemu nikt nie powie, że platforma, którą trzeba utrzymywać, goniąc zależności to zła platforma? Dawno temu doszedłem do tego, że wiele rozwiązań, które podziwiamy i które są dość rozpowszechnione wcale nie są dobre. Po prostu wydają się tanie.
Znam podobny przypadek, gdy ktoś przygotował po godzinach UI ułatwiające konfigurację firmowej aplikacji.
Projekt do użytku wewnętrznego, dostępny tylko na firmowym repo.
Od razu po prezentacji pojawiły się głosy, że ktoś to będzie musiał utrzymywać, a autor może przecież odejść z firmy.
Z mojego punktu widzenia dość absurdalny argument, bo jeśli aplikacja faktycznie przyspieszy pracę, to zawsze można przydzielić wewnętrznego maintainera.
Robiłem w tym czasie research innego narzędzia i widząc te reakcje stwierdziłem, że chyba nie warto się tym zajmować.
Myślałem, że zawsze tworzy się pełno wewnętrznych narzędzi do pracy. Tak jak prototypów. Zazwyczaj nie mają długiego cyklu życia, bo ktoś może wpaść na lepszy pomysł. Dawniej w czasach VB to chyba było normalne. Chciałbym poznać wyniki badań nad wydajnością programowania w EU. Bo wydaje się, że po 30 latach robienie takich narzędzi powinno być o wiele wydajniejsze. Nawet sam opracowałem coś szybszego do robienia UI niż VB.
To jest tylko moje anecdata, ale wydajność pracy we wszystkich polskich projektach w których uczestniczyłem była wielokrotnie wyższa od europejskich.
Problemem jest ociężały proces i biurokracja.
Mi się wydawało, że wiele wynika z tego czy jest kultura minimalizacji kosztów za wszelką cenę, czy utrzymywania (tak jak rodziny) zespołu wykwalifikowanych ludzi. Bo jeśli ta pierwsza kultura przenika do pracowników, to oni walczą o koszty, mimo że nie są beneficjentami zysków.
Dziwi mnie też strach przed utrzymywaniem. Czemu nikt nie powie, że platforma, którą trzeba utrzymywać, goniąc zależności to zła platforma? Dawno temu doszedłem do tego, że wiele rozwiązań, które podziwiamy i które są dość rozpowszechnione wcale nie są dobre. Po prostu wydają się tanie.