Wpis z mikrobloga

@cutecatboy: ogólnie urojeniem jest zakładanie, że wszystko było hiper-zoptymalizowane bo programista miał taką ambicje - nah, było bo inaczej sprzęt nie dawał rady. A teraz daje i taniej zrobić i utrzymać coś co jest nieco wolniejsze, niż od razu zoptymalizować do granic, jak nikt potem nie zauwazy zysku 1s - której koszt to jakieś 300k na optymalizację + przyszłe utrzymanie

Ps: i to decyzja biznesu, nie deva
Ps: i to decyzja biznesu, nie deva


@nilphilus: Decyzja biznesu nie leży w tym czy programiści optymalizują, tylko w tym jakich programistów zatrudniają. Managerowie nie mają nic do gadania w kwestii jaki kod piszą programiści. Obserwuję, że na ogół dobrzy programiści piszą oprogramowanie które działa szybko i piszą je szybciej niż kiepscy programiści, którzy piszą niezoptymalizowane gówno. Niezoptymalizowane gówno najczęściej jest gównem pod każdym innym względem - napisane po czasie, z
@Krolik: mówimy tutaj o trochę odrebnych rzeczach. Ty przytaczasz ewidentne błędy po stronie kodu - chociażby coś w rodzaju pomieszana iquerable z inemurable razem. Czy inne o(n^2). A ja raczej odnoszę się do kwestii architektury czy użytych technologii - i Ty chciałbyś np. Redisa zamiast cache, no bo tak to kazda instancja serwisu musi sobie to pobierac i cachowac - no ale jaki masz z tego zysk? No absurdalnie maly, za
@nilphilus: Biznes nie jest od gadania o technologiach i architekturze, tylko od określenia wymagań i ograniczeń odnośnie aplikacji. A inżynierowie są od tego aby ją budować i spełniać te wymagania.

To jest patologia wielu firm, że jakiś słabo-techniczny manager chce decydować o tym, czy inżynierowie postawią redisa czy może mongo czy postgresa. Zwykle kończy się to źle.
@Krolik: oni decydują bazujac na tym ile możesz zyskać. To jest koszt, a koszty muszą miec uzasadnienie. Oczywiście mówię tutaj o PM bardziej niż product ownerze, a PM trzyma portfel i jak Architekt powie, ze zysk jest niewielki to czemu mialby chciec za to płacić? Ps: wiele firm tez się przejeżdża na radosnej implementacji każdej nowej technologii - bo dev powiedział, ze fajna, albo po prostu ja wprowadził ;-)

Trzeba umieć
@nilphilus: stawiasz powóz przed końmi, czy jakoś tak. To nie biznes podejmuje decyzje techniczne na podstawie analizy kosztów robionej przez inżynierów, tylko inżynierowie podejmują decyzje techniczne na podstawie wymagań nakreślonych przez biznes. Jeśli biznes mówi, że projekt ma być na następny poniedziałek, ma obsługiwać 10 użytkowników i kosztować $1000 / miesiąc kosztów chmurowych, to PM bierze stażystę, kupuje mu pizzę i każe klepać kod do tego poniedziałku.

jak Architekt powie, ze
@Krolik: no to jest wspolpraca między biznesem a technicznymi. Ja się odnoszę do tego, ze zrzucanie wszystkiego na deva nie ma sensu. A w odniesieniu do początku wątku który jest o hiperoptymalizacjo to juz w ogole przesada, bo moze właśnie nikt nie chciał hiper optymalizacji bo użytkowników będzie 10
To jest patologia wielu firm, że jakiś słabo-techniczny manager chce decydować o tym, czy inżynierowie postawią redisa czy może mongo czy postgresa. Zwykle kończy się to źle.


@Krolik: Wg mnie kończy się źle jak każdy klepacz wybiera sobie technologie która jest aktualnie modna a później nie ma kto tego utrzymywać.
@Jacek12: To nie zatrudniaj ludzi którzy nie dbają o utrzymywalność projektu. Ludzie którzy dbają o długofalowy rozwój projektu nie wybierają niesprawdzonych technologii, tylko wybierają taką jaka faktycznie jest dobrze dostosowana do wymagań.

No i od wyboru technologii masz ludzi na stanowiskach takich jak #!$%@?/staff eng/architect, a w najgorszym przypadku tech lead. Zresztą to oni zatrudniają inżynierów, więc to oni powinni być odpowiedzialni za to czego używa się w projekcie.

To właśnie
@Krolik: Co z tego, że biznes zatrudni najlepszych programistów skoro nie potrafią zarządzać projektem i każą robić taski na akord? Widziałem mnóstwo projektów gdzie najlepsi programiści wypuszczali gówno, bo nie było czasu pomyśleć nad sensownym rozwiązaniem.