Jakie są najgorsze fałszywe oszczędności w tworzeniu oprogramowania? [Zamknięte]

126

Jakie są najgorsze fałszywe ekonomie (czyli sposoby oszczędzania pieniędzy, które ostatecznie kosztują więcej niż oszczędzają) powszechne w branży oprogramowania i jak z nimi walczyć?

programming-practices project-management

— Jon Hopkins
źródło

2

:( Zbyt często widziałem wiele z nich.

— Tony,

3

powiązane programiści.stackexchange.com

— questions

@Casey: To trochę powiązane, ale nie do końca. Link, który podałeś, dotyczy pieniędzy bezpośrednio, podczas gdy odpowiedzi w tym pytaniu dotyczą pieniędzy i przekonań. Przykład, patrz moja odpowiedź: programmers.stackexchange.com/questions/19573/...

— Gan

Czy właśnie odwiedziłeś moją firmę ... nieważne; P

— pramodc84

1

@ Mark - brzmi jak dobre pytanie, idź do niego. Kilka dodatkowych szczegółów może być jednak dobrych.

— Jon Hopkins,

182

Dług techniczny

tzn. „Po prostu zrób to szybko, dokonamy refaktoryzacji później”. Po pierwsze dlatego, że jeszcze nie widziałem, żeby ktoś zaangażowany w takie zachowanie faktycznie zreformował później. Po drugie, ponieważ robienie rzeczy w szybki sposób, zamiast w dobry sposób, utrudnia dodawanie przyszłych funkcji lub rozwiązywanie przyszłych błędów, aby w dłuższej perspektywie stracić czas.

Niestety wielu nadal uważa, że oszczędza to cykli programistów, aby mogli zrobić coś szybko. Myślę, że to możliwe, ale jeszcze nie widziałem tego w praktyce.

— rev Inaimathi
źródło

2

Nie mogę policzyć, ile razy widziałem, jak menedżer zatrzymał programistów (2–3) na dzień, a potem specjalista ds. Wdrażania, aby coś naprawił (i robił to wiele razy w całym cyklu życia produktu) zamiast wydawać 2- 4 dni, aby zrobić to dobrze. Świetna odpowiedź.

— DevSolo,

4

Jeśli czas potrzebny na naprawę jest mierzalny w dolarach, np. Błąd naprawić system handlu akcjami, wówczas decyzja kierownictwa skłoni się do obniżenia kosztów. Przekonałem się, że zaproponowanie „załatania go teraz, aby działało, podczas gdy my ustalamy właściwą poprawkę, aby upewnić się, że to się nigdy więcej nie powtórzy”, spełnia pilną potrzebę kosztów, a także osiąga odpowiedni wynik, ale czasami trzeba o to walczyć .

— JBRWilkinson,

9

Cały kod zawiera komentarze takie jak „To jest hack, zastąp po demo”, który był w bazie od 3 do 5 lat. Nikt nawet nie pamięta, że zostało to zrobione w tym momencie, więc nikt go nie znajdzie, dopóki ktoś (ja) nie naprawi błędów i nie przejdzie przez to. Nie trzeba dodawać, że ta lekcja obiektowa nauczyła mnie bardzo dobrze robić to za pierwszym razem, jeśli jestem w stanie to zrobić.

— CodexArcanum,

22

I szczerze mówiąc, jestem ciągle zszokowany liczbą razy, że nie oszczędza to nawet krótkiego czasu!

— PeterAllenWebb

6

@Jorg - co? „Dług techniczny i dług projektowy to synonimiczne, neologistyczne metafory odnoszące się do ostatecznych konsekwencji architektury oprogramowania slapdash i pośpiesznego tworzenia oprogramowania”. en.wikipedia.org/wiki/Technical_debt Właśnie o tym mówię. Bardziej konkretnym tytułem byłby być może „Zaciąganie długu technicznego bez zamiaru spłaty”, ale wiele osób w tej sytuacji mówi sobie, że tak naprawdę zamierza spłacić (ale nie chce), a ja chciałem uzyskać mocny tytuł pogrubiony tekst u góry. „Dług techniczny” wydawał się wystarczająco dobrym podsumowaniem.

— Inaimathi,

163

Zatrudnienie 2 tanich programistów zamiast 1 naprawdę świetnego. (za tę samą cenę)

— użytkownik2567
źródło

9

Ten przynajmniej wydaje się mieć podstawę w rzeczywistości; pamiętaj, że ludzie nietechniczni nie są w stanie powiedzieć, kim są wspaniali programiści (więc bardzo prawdopodobne jest, że zapłacą dwa razy więcej przypadkowemu, idiotycznie konsultantowi niż rzeczywistej supergwiazdie).

— Inaimathi,

112

Lub, niestety, po prostu wynająć 1 tani ...

— DevSolo,

4

... lub zatrudnienie guru, w którym dwa manekiny zrobiłyby 1,5 tego, co robi guru za 1.0 pensji guru: /

— bobah

14

Nie dostajesz 75% guru od manekina , a każdy naprawdę dobry programista zrobi to, co jest wymagane, bez snobizmu.

— Peter Boughton,

8

Programiści 10x lub 100x to niesamowicie niesamowity stosunek jakości do ceny; zarabiają tylko 1,5, może 2x. Jak mówi Michael Lopp (Rands in Repose), jeśli zatrudnisz tylko jednego z nich w całej swojej karierze, to wygrana netto.

— Tim Williscroft,

85

Mój przykład byłby całkowitym przeciwieństwem przykładu NimChimpsky'ego , a mianowicie:

Próba opracowania w domu czegoś, co można kupić z półki.

Zwykle dzieje się tak z powodu braku faktycznego sprawdzenia rynku, aby sprawdzić, czy coś już istnieje, co rozwiąże problem. Mogą to spotęgować programiści, którzy lubią „zanurzać się” w kodowaniu przed rozpoczęciem jakichkolwiek badań, oraz kierownicy projektów, którzy nie uwzględniają w tym czasie = pieniędzy.

Jednym z najczęstszych przykładów, jakie widziałem w mojej dziedzinie, tworzenie stron internetowych, są firmy próbujące opracować i wewnętrzny system CMS. Te niezmiennie zaczynają się od małych, ale wkrótce stają się wzdęte i wymykają się spod kontroli, ponieważ funkcje są włączone, podczas gdy przez cały czas istnieje wiele bezpłatnych produktów i ram, które byłyby znacznie lepiej dostosowane.

— Dan Diplo
źródło

17

To, że tak może być, nie znaczy, że powinno być. Podstawowy CMS, no tak, po co wymyślać koło. Ale kiedy zaczynasz mówić o dużych systemach i modelowaniu złożonych procesów biznesowych - po co próbować wpasowywać okrągły kołek w kwadratowy otwór? Zwłaszcza jeśli masz już własnych programistów i umiejętności.

— NimChimpsky,

9

@NimChimpsky - Myślę, że istnieją ważne przykłady obu. Z pewnością widziałem, jak ludzie psują procesy biznesowe i tracą przewagę, próbując dopasować je do gotowego oprogramowania, ale widziałem też programistów cierpiących na syndrom „nie wymyślono tutaj”, kodujący rzeczy, które mogli pobrać, ponieważ to było dla nich bardziej interesujące.

— Jon Hopkins,

3

@NimChimpsky Jeśli specyfikacja wymaga opracowania na zamówienie, to jest w porządku - utrzymuje nas w pracy :) Problem pojawia się, gdy ludzie najpierw nie sprawdzają, czy jest już coś, co pasuje do projektu i nurkują od samego początku. Trochę badań może przejść długą drogę!

— Dan Diplo,

6

Po co wymyślać koło ponownie? Ponieważ jesteś inżynierem kołowym. Lub dlatego, że twoje koło jest lepsze niż koło następnego faceta. Lub dlatego, że koło nie pasuje. Zobacz: mostlymaths.net/2010/03/…

— Derek

2

Gdzie pracuję prawie wszystko można było kupić OTS - i prawie wszystko jest ponownie wynalezione w domu, ponieważ według naszych Fearless Liderów (TM) „nasze środowisko jest tak skomplikowane, że nic na rynku może ewentualnie poradzić”. Pfeh! Ale co tam - płaci rachunki. Wczoraj powiedziano nam, że główny komponent naszego oprogramowania zostanie ponownie napisany w przyszłym roku - Z INTERFEJSEM GRAFICZNYM! Ooooooh-aaaaaaah! Jestem twitter-a ... (<pheh!>)

— Bob Jarvis,

73

Brak dedykowanych zasobów do zarządzania projektami

Kilkakrotnie doświadczyłem, kiedy zatrudniono kilku programistów, a ktoś, kto ma już wymagającą pracę dzienną, powinien był zarządzać projektem, ale w rzeczywistości był zbyt zajęty innymi zadaniami, więc projekt nigdy nie nabrał rozpędu. Programiści tworzyli „prototypy” i takie tam, ale bez przewodnika większość z nich biegała w kółko, aby wyglądać na zajętą.

Zły sprzęt dla nowych programistów

Kiedyś spotkałem firmę, w której obowiązywała zasada: „nowi programiści muszą pracować na naprawdę starym komputerze z małym ekranem, dopóki nie udowodnią, że są godni”. Nic dziwnego, że taka polityka spowodowała negatywną selekcję, która wyparła dobrych ludzi, którzy zawsze mają wybór do pracy w bardziej zdrowym środowisku.

— użytkownik 281377
źródło

19

+1. Niedostarczenie dobrego sprzętu dla twoich pracowników „skazało się na porażkę”.

— Terence Ponce,

3

+1. Należy jednak pamiętać o następujących kwestiach: w wielu firmach budżety na sprzęt podlegają infrastrukturze i są oddzielone od budżetów programistycznych. Zarządca infrastruktury nie zamierza uderzyć w swój budżet, aby pomóc zmniejszyć budżet menedżera rozwoju. Kilka razy widziałem tę paskudną politykę.

— Fil

3

Co powiesz na zły sprzęt dla WSZYSTKICH programistów? Mój były pracodawca zapłacił nam wynagrodzenie w Dolinie Krzemowej za napisanie kodu na komputerach, które były mierne pięć lat wcześniej. Z powodu przekroczonych terminów zwolnili połowę personelu rok temu, a resztę w lipcu - ale chłopcze, czy zaoszczędzili pieniądze na sprzęcie!

— Bob Murphy,

1

Kaz: Każdy programista powinien mieć odpowiednią maszynę. Jeśli zakup nowego sprzętu oznacza, że komputer nowego dewelopera jest nieco lepszy niż innych programistów, to w najgorszym przypadku masz maszyny wymiany, jeśli są to ludzie o rozmiarach dick. Normalni ludzie po prostu nie będą się tym przejmować, dopóki będą mieli ekwipunek pozwalający im na wydajną pracę. W miejscu, w którym obecnie pracuję, mam nowszy (prawdopodobnie szybszy) komputer niż osoba, która mnie zatrudniła. Ludzie, którzy przyszli za mną, mają jeszcze nowsze, prawdopodobnie szybsze komputery. Zgadnij co? Nikogo to nie obchodzi, ponieważ wszystkie nasze maszyny są wystarczająco szybkie.

— user281377,

3

Kiedy sprzęt jest nieodpowiedni, zwracam uwagę kierownictwu, zwykle wykonując pożyteczną pracę, np. Obcinając paznokcie u stóp lub czytając gazetę podczas długich kompilacji. Mam starą wolną maszynę? Jasne, nie ma problemu. Och, masz naprawę błędu pośpiechu i muszę wykonać kompilację? Jasne, panie-manager-bwana-sahib-koleś - do zobaczenia za 90 minut! (Kiedyś menedżer zapytał mnie, co robiłem cały dzień - powiedziałem mu „Ponownie zbudowałem aplikację. Cztery razy”. „W CIĄGU Ośmiu godzin?!?” Zawołał. „Nie,„ oczywiście, że nie ”, powiedziałem„ ”. Zajęło to 10 godzin ". Nowa maszyna pojawiła się niedługo po ... :-)

— Bob Jarvis

71

Możemy zaoszczędzić pieniądze, mając programistów pełniących funkcje testerów / pisarzy technicznych

Jeśli płacisz programistom wynagrodzenie za pracę testera / pisarza technicznego, to marnujesz pieniądze i prawdopodobnie dostajesz pracę niższej jakości niż ktoś, kto poświęcił swoją karierę temu zadaniu. Ponadto, gdy programiści stoją w obliczu napiętych terminów, testy i dokumentacja najprawdopodobniej zostaną porzucone lub zrobione na wpół, by je spełnić.

BTW: Deweloperzy ZAWSZE mają napięty termin.

— rev JohnFx
źródło

12

Mądrzy ludzie potrafią zrobić wszystko dobrze.

— Jon Hopkins,

3

Wprowadziłem dane, chociaż z pewnością nie zamierzałem obniżać stawek za to. Chcieli kogoś, kto byłby szybki i dokładny w zakresie niektórych krytycznych danych, i nie mieli nic przeciwko płaceniu przynajmniej potrójnej szybkości wprowadzania danych. Ich wybór.

— David Thornley,

1

Twierdziłbym, że zadaniem programistów jest testowanie ich kodu, ale nie jestem pewien, czy o to ci chodziło.

— Ben Lakey,

3

Programiści powinni przetestować własny kod, nie wykluczając posiadania dedykowanych testerów, którzy są specjalistami w łamaniu oprogramowania.

— JohnFx,

1

Zgadzam się na piśmie technicznym, nie zgadzam się na temat testowania. Testowanie jest naturalną częścią pisania dobrego oprogramowania. Pisanie techniczne to po prostu zbyt duża zmiana w stosunku do kodowania. Uważam, że muszę zmienić wiele biegów, aby przejść od kodowania do pisania technicznego i wydaje mi się, że to kiepskie wykorzystanie mojego czasu.

— Adam Bruss

63

Badanie / czytanie / pisanie kodu niezwiązanego z rozwojem produktu jest marnotrawstwem zasobów.

W to wierzą niektórzy programiści, a nawet menedżerowie. Zwykle po prostu programują w oparciu o wiedzę w ich głowach, szukają odpowiedzi i szukają odpowiedzi, gdy napotykają problemy. Nie stale aktywnie poszerzają swoją wiedzę. Moim zdaniem powinniśmy zawsze być na bieżąco, a zgromadzona przez nas wiedza byłaby dla nas przydatna w rozwiązywaniu istniejących i przyszłych problemów. Oczywiście musisz mądrze poświęcić na to swój czas.

Jest to również podobne do odpowiedzi Dana . Niektórzy menedżerowie chcą po prostu, aby programiści szybko zanurkowali i opracowali produkt zgodnie z wymaganiami bez badania istniejących produktów na rynku.

— Gan
źródło

3

Chciałbym móc to wypowiedzieć się więcej niż raz.

— MAK

1

Napiszmy bibliotekę GUI. Zbudujmy zestaw narzędzi do przesyłania wiadomości. Jeśli NIE SPRZEDAJ oprogramowania, to tylko część większej rzeczy, na litość boską, po prostu użyj implementacji innej osoby. Punkty bezpieczeństwa związane z korzystaniem z rozwiązania typu open source, zawsze możesz je naprawić i w razie potrzeby wesprzeć. Jeśli masz pieniądze na zakup rozwiązań z dołączonym źródłem, zrób to, ale strzeż się złej jakości komercyjnych komponentów oprogramowania. Sprzedawcy rzadko sprzedają ci komponent dwa razy, więc możesz być rozczarowany, gdy go posiadasz (wiem, że pracowałem w miejscach, które zostały wcześniej przez to ugryzione)

— Tim Williscroft

58

W wielu przypadkach offshoring kosztuje więcej pieniędzy. W mojej firmie bardzo trudno jest znaleźć nowe stanowiska dla pracowników, jesteśmy mocno naciskani na outsourcing. Trudno też znaleźć kontrahentów na miejscu; istnieje stosunek 3: 1 offshore do brzegu, które mają utrzymać. W związku z tym wiele zespołów po prostu wynajmuje kilkanaście jednostek offshore i prawie z nich nie korzysta, tylko po to, aby uzyskać 4 kontrahentów na miejscu.

— Jeremy
źródło

18

+1. Moje doświadczenie z offshoringiem polega na tym, że nieuchronnie kosztuje znacznie więcej pieniędzy niż oszczędza.

— Adam Crossland,

2

+1, ale offshore może działać poprawnie, jeśli zostanie użyty poprawnie

3

+1. Wydaje się, że przy każdym nowym projekcie pozyskujemy różnych programistów off-shore, co oznacza, że programiści on-shore spędzają większość czasu na nauczaniu nowych deweloperów off-shore biznesowych i technicznych modeli domen oprócz zapewniania wsparcia technicznego. Koniec projektu i zniknęły gdzie indziej, a my zaczynamy od nowa z kolejnym zestawem „tanich” programistów.

— Chris Knight

8

wiele zespołów po prostu wynajmuje kilkanaście jednostek offshore i prawie z nich nie korzysta, tylko po to, aby zdobyć 4 kontrahentów na miejscu. Łał.

— poolie

1

I zapominając, że offshoring z samej swojej natury przedłuży termin. Mamy przybrzeżną kontrolę jakości i może potrwać 3-4 dni, aby odzyskać coś, co osoby z tego samego biura mogłyby zrewanżować się w ciągu godziny z powodu różnic czasowych.

— HLGEM

50

Długie pętle zwrotne!

Zdarza się każdemu: budujesz coś, co uważasz za niesamowite, i okazuje się, że się myliłeś. To nie jest problem. Problemem jest to, ile czasu spędzasz na budowaniu, zanim dowiesz się, że powinieneś przestać.

Na wysokim poziomie widzisz ten problem z długimi cyklami uwalniania. Jeśli budujesz przez rok bez opinii, uprawiasz hazard przez cały rok. Im częściej wypuszczasz, tym mniejsze są twoje gry i tym lepiej radzisz sobie z hazardem.

Ale dzieje się to również na najniższych poziomach. Jako programista bardzo lubię częste przeglądy kodu (lub, lepiej, programowanie parami), ponieważ ogranicza to czas, w którym mogę robić coś głupiego, zanim ktoś powie: „Hej, istnieje prostszy sposób!” Z tego samego powodu lubię, aby moje testy jednostkowe działały szybko i często, dzięki czemu mogę wychwytywać i zabijać błędy, zanim będą rosły.

Gdy zaczniesz zauważać znaczenie krótkich pętli sprzężenia zwrotnego, zobaczysz je wszędzie. Np. Wojskowe pojęcie pętli OODA .

— William Pietri
źródło

6

+1. Ponadto: im dłuższa pętla sprzężenia zwrotnego, tym mniej pamiętasz o zadaniu. W skrajnym przypadku musisz ponownie zapoznać się z całą bazą kodu.

— Joseph Tanenbaum,

Jaka jest fałszywa ekonomia? Jakie są zamierzone oszczędności?

— Chris Pitman

Chodzi o to, aby zaoszczędzić czas „zmarnowany” na rzeczy, które wykonujesz w każdej pętli. Np. Budowanie, testowanie, wydawanie, zwracanie uwagi na użytkowników. W każdym razie jest to wymówka. Myślę, że jest to naprawdę zakorzenione w unikaniu dyskomfortu.

— William Pietri

Dlatego konieczne jest, aby recenzenci i parowani kumple mieli jak najwięcej pokory i szacunku dla programisty. Jeden kłopotliwy recenzent, który źle traktuje koder i możesz zagwarantować, że pętla sprzężenia zwrotnego znacznie wzrośnie.

— Jonathan Neufeld

47

Nie moja własna anegdota, ale kiedyś usłyszałem o sklepie, który przestał dostarczać bezpłatną kawę swoim twórcom, mówiąc im, że za każdym razem, gdy chcą dostać kawę, mogą swobodnie iść do najbliższej kawiarni (około dziesięciu minut podróż w jedną stronę) i kup niektóre.

Prawie definicja fałszywej gospodarki.

— EricBoersma
źródło

4

To całkiem wyjątkowe. Porównaj i skontrastuj z niektórymi bankami handlowymi w Londynie, które zbudowały w budynku subsydiowaną Starbucks, aby wyeliminować czas potrzebny na wyjście na kawę.

— Jon Hopkins,

48

Nie zgadzam się, że jest to automatycznie fałszywa ekonomia - 10 minut świeżego powietrza podczas spaceru na zewnątrz, aby kupić kawę, dotlenia pracownika i poprawi jego koncentrację, a (choć ograniczona) interakcja społeczna zmniejszy depresję, szczególnie zimą. Pracownicy, którzy nie dostaną kawy, ponieważ nie jest ona bezpłatna, prawdopodobnie wrócą do domu na czas, więcej snu i będą mieli lepsze zdrowie ze względu na zmniejszone spożycie kofeiny.

— JBRWilkinson

6

-1, 20-minutowy spacer jest idealny, aby uwolnić umysł i uzyskać świeże spojrzenie na problem.

— Malfist,

23

@Malfist: Tak jak to zrozumiałem, nie tylko 20-minutowy spacer, ale także 15-minutowe oczekiwanie na kawę, która przerwała pracę. 45-minutowa przerwa w dowolnym momencie dnia praktycznie zniszczy produktywność przez ponad półtorej godziny. Wszystko po to, by zaoszczędzić 100 dolców miesięcznie na kawie.

— EricBoersma,

8

20 + 15 = 35 [jeszcze sześć znaków]

— Malfist

47

Udostępnianie stacji roboczych z jednym ekranem, ponieważ drugi monitor jest zbyt drogi . Nawet jeśli oszczędza to tylko godzinę pracy każdego roku, drugi ekran jest nadal dobrą inwestycją. Wiem na pewno, że mój zaoszczędził mi wiele, wiele godzin pracy.

Konfiguracja wielu monitorów może sprawić, że prawie każde zadanie będzie bardziej wydajne, nie tylko zadania programistyczne. Trzy monitory są nawet lepsze niż dwa, ale efekt staje się mniej wyraźny z każdym dodatkowym ekranem.

Konfiguracje dla wielu monitorów:

zmniejszyć narzut przełączania okna
pozwalają mieć oko na rzeczy działające w tle (poczta, kompilacja itp.).
dać ci poczucie wolności. To jak bycie w atrium vs. bycie w szafie na miotły.
itp...

— rev Arjen Kruithof
źródło

2

Raz zmierzyłem się dokładnie z tym problemem. Napisałem maila do jednego z naszych dyrektorów generalnych, który wyliczył, że biorąc pod uwagę wzrost wydajności o 5%, zaoszczędziłbym kwotę wartą monitorowania w ciągu około pół miesiąca w stosunku do mojego dochodu netto. Ta kalkulacja była dość żelazna ... ale ... Myślę, że znasz już koniec historii :)

— Raffael,

39

Najtańszy sprzęt podany konsultantowi, gdy kosztuje on ponad 150 $ / godzinę .

Ujmując to z perspektywy czasu, lepszy sprzęt może przynajmniej zwiększyć wydajność pracy o 30 minut dziennie. To dałoby 30min * 20 dni pracy na miesiąc = 600min / miesiąc = 10 godzin / miesiąc> więcej niż 1 dzień pracy = 10 godzin * 150 $ / godzina = 1500 $

Czy konsultant nie byłby bardziej wydajny, gdyby miał komputer za 1500 $? Czy sprawiłoby to, że konsultant byłby mniej zirytowany?

Teraz wydaje się, że problem polega na tym, że istnieją dwa budżety, jeden dla konsultanta i jeden dla sprzętu komputerowego.

— Amir Rezaei
źródło

8

Jako konsultant byłem tam, zrobiłem to i dostałem koszulkę. (Ale dostałem tylko 80 $ za godzinę.) Ale hej, to jeden z powodów, dla których lubię kontraktowanie co godzinę. W przeciwieństwie do pracy najemnej, jeśli klient konsultingowy zdecyduje się marnować mój czas i muszę dodatkowo pracować, aby to nadrobić, to więcej pieniędzy w mojej kieszeni.

— Bob Murphy,

2

Bez obrazy, ale jeśli płacę 150 $ za godzinę za konsultanta, powinien mieć swój własny komputer.

— Steven Evers,

8

@SnOrfus: Zwykle nie działa to w środowisku korporacyjnym, gdzie istnieje ścisła kontrola komputerów dozwolonych w domenie. Musisz zapewnić im sprzęt.

— HardCode,

1

@HardCode - Tak, tak sądzę. Teraz rozumiem o co chodzi.

— Steven Evers,

3

@HardCode W ostatnim projekcie zamiast dodania nas (kontrahentów) do wewnętrznej sieci firmowej poddali nas kwarantannie do naszej własnej linii DSL. Dedykowana linia DSL dla 3 programistów @ 40 USD miesięcznie to łatwa zmiana i ułatwiło nam zdalne przekazywanie aktualizacji bez wywoływania paniki wśród personelu IT. Ponadto, jeśli komputer produkcyjny z naszym kodem zostanie zainfekowany i ulegnie awarii, jest to automatycznie nasza wina, ponieważ jesteśmy odpowiedzialni za bezpieczeństwo naszej komunikacji i laptopów osobistych. Czy możesz powiedzieć wygrana-wygrana-wygrana?

— Evan Plaice,

38

Miesiące pracy oszczędzają dni planowania

(Niewystarczająca ilość czasu na planowanie)

— serg
źródło

21

W szkole podstawowej było powiedzenie, że kilka tygodni w laboratorium może zaoszczędzić godzinę czasu w bibliotece.

— David Thornley,

7

Tak. Kiedy brałem udział w zajęciach laboratoryjnych, na których zidentyfikowaliśmy nieznane chemikalia, profesor powiedział nam: „godzina w bibliotece uratuje was czterech w laboratorium”. Wziąłem go na poważnie i zabawnie było wchodzić do laboratorium przez godzinę w tygodniu i patrzeć nieprzyjemnie na pre-meds, którzy spędzali dwanaście godzin tygodniowo na testach aminowych związków, które najwyraźniej nie były aminami. A kiedy kilka lat później prowadziłem to samo laboratorium, udzielałem uczniom takich samych rad i tak jak niewielu faktycznie je przyjęło.

— Bob Murphy,

3

Jeśli nie uda Ci się zaplanować, planujesz się nie udać

27

Podejrzewam, że najbardziej rozpowszechnionymi są menedżerowie, którzy po prostu nie zapewniają programistom narzędzi potrzebnych do wydajnego wykonywania pracy.

Zasadniczo punkt 9 w teście Joela .

— richeym
źródło

2

Pracowałem nad projektami, w których zmarnowalibyśmy tydzień lub dwa zamiast kupować, na przykład, bibliotekę za 300 USD z już wykonaną pracą - i lepiej (nie jesteśmy „programistami kontrolującymi”, w których pracuję). Lub wybierz jakieś narzędzie programowe ”, ponieważ zostało stworzone przez„ tę lub inną ”firmę, zamiast szukać lepszych alternatyw, a następnie uczyń nasze życie piekłem na lata.

— MetalMikester,

Sam na to wpadłem. Rozumowanie PM / klienta było takie, że nie mieliśmy pozycji w budżecie na zakup rzeczy dla klienta (zmiany w kontaktach były dziwką), więc musielibyśmy ponownie wynaleźć koło (ponownie).

— Ken Henderson

24

Niestety, w niektórych miejscach wciąż można stosować „rzucanie (wystarczającą) ilością ciał” . Prawo Brook'a przeczy temu w The Mythical Man-Month , choć niektórzy wymagają doświadczenia, aby nauczyć się tej lekcji. Zasadniczo nie mogę tego powstrzymać, ponieważ kierownictwo może wierzyć w fałszywe oświadczenie o dodawaniu ludzi i niepłaceniu za to ceny.

— JB King
źródło

2

+1. O Boże tak. Obecnie dzieje się to na wielką skalę w dużym projekcie, w którym pracuję.

— Tabele Bobby'ego,

3

Współpracuję z grupą liderów projektów, menedżerów itp., Z których wszyscy mają tak wspaniałą certyfikację zarządzania projektami (niezależnie od tego, jak się to nazywa) i ŻADEN Z nich nie słyszał o The Mythical Man-Month przed ich przedstawieniem do tego. Do licha!

— Bob Jarvis,

2

Słyszałem kiedyś świetny cytat na ten temat: 9 kobiet nie może urodzić dziecka w ciągu miesiąca

— Richard

@Richard Użyłem tego na spotkaniu. sprawił mi ogromną przyjemność!

— Tjaart,

21

Codzienne spotkania :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...

— Zzz
źródło

9

Spotkanie tylko po to, żeby się spotkać ...

— Gan,

5

Porządek obrad na dziś: Co znajdzie się w porządku obrad na jutrzejsze spotkanie?

— Mark C

9

Codzienne spotkania są w porządku, jeśli są krótkie; 3-minutowe spotkania w stylu Scrum nie marnują dużo czasu, ale informują wszystkich o postępach innych. Długie spotkania z licznymi bezinteresownymi uczestnikami są jednak toksyczne.

— 9000

3

@Mark C - Może to zabrzmieć jak żart, ale tak naprawdę zostałem zaproszony na spotkania, aby zaplanować program spotkania na najbliższe dni ...

— Gavin Coates,

@Gavin Coates to rzeczywistość i sytuacja ... :)

— Zzz

20

Kupowanie gotowego oprogramowania zamiast rozwijania go wewnętrznie.

Mam doświadczenie w zakresie systemów zarządzania na skalę przedsiębiorstwa, koncentrujących się zarówno na HR, jak i na laboratoriach biologicznych.

Gotowe rozwiązanie kosztowało 50-100 tys. Funtów i wymagało dalszego rozwoju i dostosowywania do wymagań biznesowych.

Opracowanie wewnętrznego rozwiązania zajęło (<6) miesięcy, a równolegle pracowano nad innymi projektami i wykorzystano już zatrudnionego programistę.

Przeszedłem z sektora publicznego, w którym uruchomiliśmy wewnętrznie opracowany LIMS (system zarządzania informacjami laboratoryjnymi), do dużego międzynarodowego farmaceutyka, w którym wdrożenie gotowego rozwiązania zajęło ponad rok i nie było kompletne.

(6 miesięcy już zatrudnionego programisty pracującego równolegle nad innymi projektami. Więc około 10 tys. A to nie obejmuje kosztów wsparcia związanych z gotowym rozwiązaniem). Najważniejsze jest to, że faktycznie opracowano wewnętrznie opracowany system! Masz więc dodatkowe korzyści związane z kosztami, których nie mogę obliczyć.

Zgodziłbym się na podstawowe strony internetowe itp., Po co zawracać sobie głowę tworzeniem własnych. Ale dla każdego dużego złożonego systemu i jeśli masz już umiejętności domowe, zbudowałbym go sam .

— NimChimpsky
źródło

26

Założę się, że jest też wiele przykładów przeciwnych.

— Jon Hopkins,

13

Kupowanie lub rozwój sprowadza się do właściwych osób dochowujących należytej staranności. Proste. Pomyśl, zanim zrobisz. (+1)

— DevSolo,

4

@DevSolo: spot on. Decyzja o budowie lub zakupie powinna być poparta analizą kosztów i korzyści, a nie emocjonalnym podejściem „nie wymyślono tutaj” lub „kocham oprogramowanie XXX”.

— JBRWilkinson

9

Jeśli zamierzasz przedstawić ogólne oświadczenie dotyczące kompilacji a zakupu, powinno być: wolę kupować rozwiązania problemów, które nie są częścią podstawowych kompetencji Twojej firmy. Nie zawsze jest to właściwa odpowiedź, ale jest rozsądną pozycją domyślną i mniej więcej tak wiarygodną, jak stereotyp. Stwierdzenie, że zakup gotowego oprogramowania jest fałszywą ekonomią, nie jest nawet użytecznym frazesem. Czuję twój ból związany z rozwiązaniami „E” (co powinno oznaczać „Enterprise”, ale tak naprawdę oznacza „Drogie” ”). Ale obecność złych opcji nie oznacza, że nie ma dobrych.

— evadeflow,

2

Myślę, że problem polega na zakupie, a następnie na dalszym rozwoju i dostosowywaniu , koszt niewielkiej personalizacji dużego wprowadzonego systemu często może być większy niż napisanie własnego małego systemu, który robi to, co chcesz. Kup więc, jeśli możesz pracować tak, jak kupowany system oczekuje od ciebie pracy, ale kup i dostosowywanie mogą dać gorsze strony!

— Ian

15

Kupowanie drogich, gotowych produktów, gdy alternatywy open source są lepsze i bezpłatne.

Ile firm używa git? Ile firm korzysta z jakiejś gównianej, przedsiębiorczej kontroli wersji?

— hasen
źródło

1

Ehm, czy można to uznać za „najgorszą fałszywą ekonomię”? A może potrzebujesz rozwinąć więcej ...?

— Gan

3

Nie jestem pewien, czy przynajmniej całkowicie zgadzam się z przykładem kontroli źródła. Git został specjalnie zaprojektowany do rozwiązywania problemów typu open source: wielu programistów, niewielka centralna kontrola, wiele oddziałów itp. „Przedsiębiorcze” oprogramowanie działa przy różnych założeniach: potrzeba zarządzania różnorodnymi produktami w firmie, bezpieczeństwo, przepływ pracy itp.

— PeterAllenWebb,

1

@Gan: Myślą, że korzystanie z otwartego oprogramowania jest fałszywą ekonomią, ale mają to wszystko wstecz.

— hasen

3

Jestem współautorem X11 i GNOME, a także dość kompetentny w używaniu git i administrowaniu serwerami gitosis. Niemniej jednak tego lata zmieniłem pracę konsultingową z git na osobiście opłacany serwer Perforce, ponieważ robi on wiele rzeczy automatycznie, które musisz robić ręcznie z git. Ponieważ dostaję wynagrodzenie za dostarczanie kodu i nie przejmowanie się kontrolą wersji, używanie i płacenie za „gównianą, korporacyjną kontrolę wersji” jest znacznie bardziej opłacalne niż używanie git.

— Bob Murphy,

7

Z mojego doświadczenia wynika, że oprogramowanie typu open source kontra produkty komercyjne to tak naprawdę „przypadek”.

— MetalMikester,

14

Używanie „prostych” języków bez dużej ekspresji

Tak, łatwiej jest znaleźć programistów do obsługi kodu, ale trudniej jest znaleźć dobrych programistów, którzy nie tylko uczą się najnowszego modnego hasła, które ich zatrudni. Tak, ułatwia zrozumienie kodu poszczególnych bitów, ale czyni go tak sztywnym jak 2x4 i zwiększa objętość kodu, który należy zrozumieć. Tak, jest wspierany przez wielką korporację, ale powiedział, że ogromna korporacja wprowadza innowacje powoli i biurokratycznie.

— dsimcha
źródło

4

@burnt_hand: Mówię w zasadzie o nadmiernej niechęci kierownictwa do wyboru języka.

— dsimcha

1

+1: Po prostu używaj C, ponieważ „mamy te umiejętności, a nauka nowego, wymyślnego języka, takiego jak Python / Perl / PHP, zwiększa ryzyko”. Słyszałem to więcej niż raz. Czy to oznacza, że zespół jest zbyt głupi, aby uczyć się nowego języka?

— S.Lott,

1

@ S.Lott Agenci rekrutacyjni myślą, że jesteś !, ale to już inna historia

— burnt_hand

2

tj. firmy, które trzymają się Java i C # i zbyt boją się dotykać pytona lub rubinu, ponieważ nie są one „standardem branżowym”, co przypomina mi: paulgraham.com/avg.html

— hasen

1

@hansen: Esej Paula Grahama częściowo zainspirował mnie do napisania tego postu. Inną inspiracją była moja praca nad tworzeniem bibliotek (w tym biblioteki standardowej) dla języka programowania D.

— dsimcha

13

Zli kierownicy projektów / kierownicy zespołu.

Ponieważ jedna niekompetentna osoba ma moc zrujnowania pracy grupy ludzi. Ostatecznie projekt byłby o wiele lepszy bez decyzji kierownictwa wyższego szczebla (kierownika projektu / zespołu).

Dozuj decyzję „Po prostu zrób to szybko, dokonamy refaktoryzacji później”.

— Amir Rezaei
źródło

4

Zgadzam się, że są źli menedżerowie, ale „projekt poradziłby sobie znacznie lepiej bez decyzji kierownictwa wyższego szczebla”? Zasadniczo są to ludzie, którzy sponsorują projekt. Wydaje mi się to trochę jak programiści, których poznałem, którzy uważają, że zrozumienie technologii jest ważniejsze niż zrozumienie biznesu i zapomnienie, kim jest rzeczywisty klient.

— Jon Hopkins,

2

@Jon Hopkins Z wyższym kierownictwem nie polecam klienta. Chodzi o to, że „źli menedżerowie projektów” to ci, którzy popełniają błędy po błędach i sprzeciwiają się grupie ludzi. Jak myślisz, kto decyduje „Po prostu zrób to szybko, dokonamy refaktoryzacji później”. Przeczytaj odpowiedź z najwyższą stawką!

— Amir Rezaei

ach, jaśniej. Usuwam moje -1.

— Jon Hopkins,

Zauważyłem niepokojący trend kierowników projektów odwracających czas i koszty w stosunku do jakości. Jestem pewien, że nie jestem jedyny. PM lubią korzystać z diagramu trójkąta z kosztem / jakością / czasem, ale jakość zawsze dostaje pierwszeństwo. To bardzo smutne, a zinstytucjonalizowanie i wymuszenie wskaźników zarządzania projektami (PMI) na czymś tak skomplikowanym, jak oprogramowanie wydaje się tylko pogarszać sytuację.

— Bernard Dy

1

@Bernard - czas i koszty są mierzalne. Jakość? Nie tak bardzo. Smutne, ale prawdziwe IMO ...

— Bob Jarvis,

12

Brak wymagań użytkownika

Ważnym i trudnym krokiem przy projektowaniu oprogramowania jest określenie, co tak naprawdę chce klient.

Wierzcie lub nie, czasem brakuje tej części lub jest ona nieaktualna. Koszt polega na tym, że tworzy się funkcje, o które użytkownik końcowy nigdy nie prosił.

— Amir Rezaei
źródło

Myślę, że to powinno być na szczycie!

— Roopesh Shenoy,

8

Wydajność jest warta więcej niż kreatywność

Kreatywność jest trudna do zmierzenia i najczęściej niemożliwa do zaobserwowania, nie wspominając o pomiarze, jeśli chodzi o rozwój oprogramowania. Z drugiej strony produktywność można zmierzyć (często słabo) i można ją zaobserwować.

W rezultacie programiści, którzy potrafią (pisać więcej linii kodu | pisać kod szybciej | recytować technobabble szybciej w odpowiedzi na pytania | są bardziej widocznie produktywni), są zwykle cenieni bardziej niż ci, którzy (używają mniej linii kodu, aby rozwiązać ten sam problem | więcej czasu zajmuje napisanie kodu, ale stworzenie bardziej niezawodnego produktu | zrozumienie tematu wystarczająco dobrze, aby odpowiedzieć na pytania w prosty, łatwy do zrozumienia, angielski | twórczo rozwiązać problemy).

— Blueberryfields
źródło

6

Wszystkie poniższe informacje mogą być złe, jeśli są używane lub nie są używane niewłaściwie

oprogramowanie zewnętrzne vs wewnętrzne
Zgodność z ISO 9001 (oszczędność - ograniczenie ryzyka utraty MSS w przypadku spadku jakości produktu)
outsourcing rozwoju / kontroli jakości
procedury rozwoju / kompilacji / wydania / wsparcia

— Bobah
źródło

W jaki sposób ISO 9001 jest „fałszywą” „ekonomią”?

— Andrew Grimm,

@Andrew Grimm - zgodność zapewnia pewien poziom jakości, który ogranicza ryzyko wynikające ze złej jakości (na przykład utrata MSS), dzięki czemu potencjalna ekonomia jest jasna. W przypadku małych działów może to być nieodpowiednie, ponieważ straty na

— kosztach

1

@Andrew - z mojego doświadczenia wynika, że chcesz tego. Jeśli chcesz, aby podniosła jakość, prawdopodobnie jest to fałszywa ekonomia, ponieważ zwykle jest droga i może źle dopasowywać się do oprogramowania. Jeśli chcesz, aby była to sprawa marketingowa lub dlatego, że jest to oczekiwane w Twojej branży, to potencjalnie jest to dobry pomysł.

— Jon Hopkins,

5

@Andrew Grimm - „Jedyną” rzeczą, którą gwarantuje ISO 9001, jest stała, powtarzalna jakość. Nie gwarantuje to „wysokiej” jakości. Jeśli jednak wymagana jest kwalifikacja ISO 9001 na rynku, na którym firma chce się znaleźć, to jest ona wymagana.

— Vatine

1

@Vatine: Gwarancją ISO 9001 jest spójny, powtarzalny proces. Jest to ważne w niektórych dziedzinach, w których spójne procesy zapewniają stałą jakość. Nie gwarantuje to wysokiej jakości, ale jeśli klient zobaczy coś, co zrobiłeś dobrze i wie, że masz certyfikat ISO 9001, będzie pewny podobnej jakości.

— David Thornley,

4

Posiadanie zbyt wielu menedżerów dostaw niepodlegających rozliczeniu.

Kilka lat temu w naszej firmie mieliśmy kilka dużych projektów budżetowych, a rekrutacja była na szczycie. W tym czasie nasza firma zatrudniła zbyt wielu kierowników dostaw (wielu z nich nie było IT!) I bardzo mało programistów / testerów. Stosunek menedżera do programisty wynosił dosłownie 1: 2. Później, po zakończeniu tych projektów, mieliśmy sytuację, w której wielu z tych menedżerów (niektórzy z nich byli prawdziwymi zwolennikami) siedzieli na ławce i nic nie robili. Mieliśmy jeden cykl oceny, w którym wszyscy otrzymywali niewielkie / żadne podwyżki (nawet nas, pracowitych programistów, westchnienie), aby firma nie musiała nikogo zwalniać! Na szczęście firma zdała sobie sprawę z tej sytuacji i przeprowadziła RIGHTSIZING w pierwszym kwartale tego roku!

— mananjani
źródło

3

Optymalizacja przed profilowaniem (inaczej przedwczesna optymalizacja).

Zbyt wiele razy widziałem, jak ktoś sięgał po sprytne rozwiązanie, które niepotrzebnie komplikuje konserwację i czytelność, ponieważ jest szybsze. Oczywiście kod nie został oznaczony (nawet w przypadku mikro-testów), więc szybko staje się „szybszy w oparciu o bardziej przekonujący argument” w części kodu, która najprawdopodobniej nie wpłynęła na ogólną wydajność całego aplikacja znacznie.

Jako taka, jest to bardzo fałszywa ekonomia i rodzaj fałszywej ekonomii, która czasami uwikłuje nawet doświadczonych profesjonalistów.

— Edwin Buck
źródło

3

Ograniczony lub brak dostępu do Internetu

Ponieważ oczywiście Twoi pracownicy będą korzystać z Internetu do grania w gry na Facebooku, nie szukając odpowiedzi na pytania techniczne dotyczące Stackoverflow.

W rzeczywistości Internet jest ogromnym wzrostem wydajności i chociaż może być właściwe użycie pewnego rodzaju filtru strony dla naprawdę podejrzanych stron, jest coś nie tak, jeśli blokuje plik readme ze studia wizualnego lub blokuje strony rządu Telford z jakiegoś powodu „turystyka seksualna”

— jk.
źródło

2

Zmuszenie programistów do korzystania z 15-calowego monitora i komputera o niskiej specyfikacji, ponieważ jest to standard korporacyjny.

Monitory o rozsądnych rozmiarach są tanie, szybkie w instalacji i zwiększają produktywność programistów, a także sprawiają, że programiści myślą, że ci na nich zależy.

— Ian
źródło

2

Zbyt wielu licencjatów administracji biznesowej (lub im podobnych), hierarchicznie zorganizowanych, którzy starają się zastosować to, co ich zdaniem dotyczy współczesnego zarządzania: przeszkadzanie ludziom z „kluczowymi wskaźnikami wydajności”, „umowami SLA” i tym, co nie, wymagające „raportów” (bez, oczywiście, dbając o infrastrukturę, aby je wygenerować), aby programiści marnowali swoje dni na wypełnianie fantazyjnych arkuszy EXCEL, raportów z czwartego kwartału i tego, co nie, i kopiowanie z jednego wspaniałego nowego narzędzia do zarządzania i wklejanie do innego (wydaje się, że regułą jest narzędzia te nigdy nie są zintegrowane ani integrowane ze sobą) i biorą udział w spotkaniach, na których prezentowane są raporty i dane liczbowe (i wszyscy czują się winni, że nie wypełnili tego lub innego KPI).

— Ingo
źródło