Natknąłem się na link do Wybierz nudną technologię autorstwa Dana McKinleya za pośrednictwem jednego z moich kanałów społecznościowych Slack. Skłoniło mnie to do zastanowienia się nad wzajemnymi powiązaniami: złożoności i długu technologicznego, produktywności i szybkości programistów, kultury inżynierskiej i podejmowania decyzji. Ostatecznie doszedłem do wniosku, że kultura podejmowania decyzji — sposób podejmowania decyzji — ma ogromny wpływ na długoterminową produktywność organizacji inżynierskiej.

Najpierw kilka najważniejszych informacji z Boring Technology. Trzy kluczowe elementy, które rezonują ze mną:

1. Długoterminowy koszt utrzymania technologii dominuje nad całkowitym kosztem i znacznie przewyższa krótkoterminowe korzyści związane z prędkością.

Mamy tendencję do skupiania się na korzyściach płynących z nowej technologii, nie zawsze w pełni uznając bieżące koszty utrzymania — które często dominują w dłuższej perspektywie.

Sposób, w jaki się zachowujemy, naprawdę zależy od tego, w co wierzysz, który termin dominuje w tym równaniu w prawdziwym świecie.

Jeśli technologia jest naprawdę droga w obsłudze, dominują koszty. Jeśli technologia naprawdę ma ogromny wpływ na to, jak łatwa jest twoja praca, przeważają korzyści.

#48

2. Ludzie (często) mają bardzo duże zdanie na temat wyboru bazy danych…

Znalazłem się na tej liście osób, które są bardzo uparte, ale bardziej z powodów związanych z faktem, że dokładnie rozumiem, ile czasu i wysiłku wymaga zbudowanie specjalistycznej wiedzy wymaganej do prawdziwego zrozumienia konkretnego RDBMS lub technologii przechowywania danych.

Z mojego doświadczenia wynika, że ​​w tym miejscu odpadają koła. Ludzie tracą swoje gówno i zaczynają bić w bębny programistów poliglotów. Jest coś w pomyśle dodania nowej bazy danych, w której ludzie szturmują Bastylię, mówiąc: „nie możesz nas powstrzymać przed użyciem najlepszego narzędzia do pracy, człowieku”.

A kiedy ludzie ulegają temu instynktowi, mówią sobie, że dają programistom wolność. I oczywiście jest to wolność, ale jest to bardzo wąska definicja tego, czym jest wolność. #36

Chodzi o to, że opinia i pojęcie wolności i/lub satysfakcji mogą zdominować narrację o wyborze technologii, jeśli nie ma solidnego procesu podejmowania decyzji.

3. Ostatecznie naszym celem w budowaniu i utrzymywaniu produktów (systemów) jest wspieranie pomyślnego wyniku biznesowego. Nie po to, by budować wymyślną technologię.

Wracając do moich pierwszych doświadczeń ze start-upem SaaS — zbudowaliśmy Eloqua na nudnej technologii — Visual Basic (nie żartuję, to był rok 2000), SQL Server, IIS.

W ciągu tych pierwszych kilku lat zbudowałem kilka nudnych narzędzi (zgadliście — również w języku Visual Basic) do automatyzacji wdrożeń i wykonywania podstawowego monitorowania punktów końcowych. (To była chmura przedpubliczna, ludzie!). Moim głównym celem była oszczędność czasu i ograniczenie błędów we wdrożeniach — mieliśmy bardzo szczupły zespół, a te narzędzia znacząco poprawiły naszą efektywność.

W 2008 roku, osiem lat po rozpoczęciu działalności firmy, mój dziewięcioosobowy zespół „Production Operations” wspierał centrum danych, cały sprzęt i infrastrukturę, wiedzę na temat sieci i baz danych. Codziennie obserwowaliśmy kilkadziesiąt milionów transakcji. W IV kw. 2008 utrzymaliśmy dyspozycyjność na poziomie 99,998% i udało nam się to przy jednoczesnym obniżeniu kosztów na tym naprawdę nudnym stosie technologii.

Oczywiście ten nudny stos w Eloqua wyglądałby zupełnie inaczej, gdybyśmy zbudowali go przy użyciu technologii dostępnych w ciągu ostatnich pięciu do dziesięciu lat. I byłyby znaczące korzyści, które moglibyśmy zaobserwować dzięki niektórym konkretnym technologiom. Jednak przy obecnych dostępnych technologiach łatwość uruchamiania nowej usługi zarządzanej musi być porównywana z długoterminowym całkowitym kosztem posiadania.

Dlatego:

Powinieneś mieć proces dodawania technologii do swojego stosu, który obejmuje rozmowę z innymi ludźmi. #86

Jak podchodzisz do podejmowania tych decyzji w skali ponad 20 zespołów?

We FreshBooks spędziliśmy dużo czasu, pracując nad tymi pytaniami, i ostatecznie pracowaliśmy nad zapewnieniem jasności i treści procesu decyzyjnego, używając:

• Dokumentacja inżynierska w celu przejrzystego udokumentowania ważnych, powoli zmieniających się informacji i procesów, które są ważne dla organizacji
• Ramy decyzyjne pomagające zespołom zrozumieć, jakie decyzje można podejmować na poziomie zespołu, a jakie na poziomie organizacji, oraz gdzie szukać dokumentacji
• Wewnętrzny Radar Technologiczny opisujący narzędzia, technologie, które powinny i nie powinny być adoptowane
• Proces prośby o komentarze (RFC) dotyczący ram oceny i zalecania nowych podejść lub technologii
• Rekordy decyzji architektonicznych (ADR) do dokumentowania decyzji

Niedawno zdecydowałem się odejść od FreshBooks, ale mam nadzieję, że to zbiorowe podejście doprowadzi do trwałych decyzji, zmniejszonej złożoności i zwiększonej produktywności. ( Ludzie FreshBooks — bądźcie szczerzy i dajcie mi znać, jak to się potoczy… )

Powrót do Eloquy. Przez większą część historii firmy dokonywaliśmy naszych nudnych wyborów technologicznych z konieczności. Stworzyliśmy nową kategorię — Marketing Automation — ale mieliśmy kulturę, która była postrzegana (i prawdopodobnie była) na niskim poziomie innowacji technicznych. Nie mieliśmy silnego procesu decyzyjnego, ale na nasze decyzje duży wpływ miała potrzeba wspierania strumienia przychodów B2B przedsiębiorstwa.

Ostatecznie sprzedaliśmy firmie Oracle firmę Eloqua i jej nudną technologię za prawie 900 mln USD. Jestem prawie pewien, że powtarzające się przychody i tempo wzrostu przychodów były ich głównym interesem w tej transakcji… a nasze nudne wybory technologiczne po prostu przeszły due diligence.