Na początek problem, który pojawił się na forum 4p. Standardowe rozwiązanie czyli maglowanie opcji JVM nie pomogło zatem zasugerowałem dwa rozwiązania. Pierwsze podział zbioru danych, drugie zmianę środowiska na 64bitowe.
Odpowiedź znalazła uznanie, ale na koniec pojawił się nieprzyjemny zgrzyt:

Czas opieprzyć programistów

Moim zdaniem nie ma to najmniejszego sensu. Z kilku powodów.

Programista też człowiek

Zatem nie tylko może się mylić, ale zazwyczaj się myli. Praca programisty polega na wykonaniu zadania. Jeżeli zadanie zostało wykonane poprawnie od strony formalnej to opieprzanie go za to jest najzwyczajniej w świecie głupie. Trochę jak w dowcipie:

Szef Googla do sekretarki:
– Kupiłaś mi Motorolę jak prosiłem?
– Tak.
– Jaki model?
– Model?

Współczesne systemy informatyczne są zbyt skomplikowane by ogarnąć wszystkie zagrożenia. W dodatku niektóre z tych zagrożeń są całkowicie niezależne od osoby odpowiedzialnej za dany system. Przykład z linku to duża ilość danych.

Kolejna sprawa to należy popatrzeć też na siebie i swój kawałek odpowiedzialności. Czy powiedziałem ILE tych danych może być? Czy szacunki były prawidłowe? Czy podejmując decyzje na poziomie projektu brałem pod uwagę to co sugerowali mi programiści? Bardzo często problemy rodzą się z niedoszacowania lub przeszacowania pewnych elementów.
Przykład bieżący z życia mego to problem z nową funkcjonalnością systemu, która wymaga innej konfiguracji DBMS. Tyle tylko, że kiedyś pisząc założenia do tego systemu nikt nie wziął pod uwagę jego rozwoju i nie przygotował odpowiedniego zaplecza. Dziś to ja mam problem.

Jak nie opieprz to co?

No właśnie. Programiści to ludzie co do zasady inteligentni. Jest jednak pewna cecha, która dotyczy ich wszystkich bez wyjątku. Tą cechą jest ciekawość i kombinatorstwo. Zamiast opieprzać należy przedstawić problem do rozwiązania. Pokazać gdzie obecne rozwiązanie ma słabe punkty i jakie wyniki powinny być zadowalające (zrób rachunek sumienia by później nie zawracać im znowu dupy z powodu złego oszacowania). Przy czym nie można tego zrobić za pomocą „idioto popraw to”.
Znacznie lepszym stwierdzeniem jest „zoptymalizuj to”. Dlaczego?
Dwie zasady optymalizacji Michaela Jacksona (zbieżność nazwisk przypadkowa):

  • Nie optymalizuj.
  • Dla ekspertów – jeszcze nie optymalizuj.

Programiści je zazwyczaj stosują. Pozwalając im na optymalizację dajemy sygnał do startu. Rzucą się na problem jak stado wygłodniałych studentów trzeciego roku na darmową pizzę i piwo.

Zatem główna zasada zarządzania w IT jak trzeba coś poprawić – daj programistom zadanie zamiast opieprzu. Ty będziesz miał sprawę z głowy, a oni satysfakcję.