Низкий КПД, часть II

Felix IT
3 min readJan 28, 2017

--

Продолжим.

Всем плевать на стандарты. Нет, правда. Разработка породила тысячи стандартов (даже потешный на голубиную почту). Всякие RFC, ANSI, ISO, W3C, IEEE и т.д. Всем пофиг. А, ещё пофиг потому, что иные стандарты писал, кажется, Лев Толстой (1300+ страниц норм?), потому их прочтёт и поймёт только упоротый робот. А иные стоят нехилых денег, потому вы не купите их образования ради (я вот которую неделю раздумываю о покупке стандарта C++ на русском, но 5К рублей, потому лишь раздумываю).

Когда у вас в браузере поехала вёрстка, иногда виноваты не кривые лапки фронтендера, но то, что производитель (вендор) браузера на свой манер прочёл спецификацию. Если вообще прочёл.

Когда отдел QA в десятый раз возвращает сервис обратно, разработчик проклинает день, в который решил переехать с одной RDBMS на другую. Обе поддерживают стандарт SQL, но… но с нюансами.

Когда сервис внезапно падает с нечитаемой ошибкой после обновления пары пакетов, виноват иногда не бекендер, но очередной Вася, решивший, что можно стандарт трактовать и эдак. А другой Вася вообще вместо стандарта читал статью про стандарт, потому библиотека свалилась на пустом месте.

В общем, всем весело. Знаете, какую культуру разработки это породило? Культуру “какой стандарт? ничего не знаю, я так вижу”. После чего одни Васи раз за разом наступают на одни и те же грабли, а другие раз за разом воюют с тем, что в угаре наклепали первые.

КПД фронтендера, который ради одного красиво всплывающего элемента меню убивается в десяти браузерах, в которых потом так же убивается тестировщик, можете представить.

КПД бекендера, который читал стандарт и попытался написать согласно прочтённому, но столкнулся с тем, что всё упало, тоже можете представить.

Угадывание вместо планирования. Взять десять программистов, дать одну маленькую задачу и через сутки получить десять разных решений. Попросить обоснование решения и устроить перекрёстный code review — получить птичий базар, на котором каждая птица на 146% уверена в своей правоте. Это раз.

Взять десять тимлидов и попросить отреагировать на одну и ту же ситуацию — получить десять разных реакций. Попросить обосновать реакции — получить совершенно невероятные версии, которые никак не будут отвечать действительности (об этом позже). Это два.

Взять десять команд и попросить написать сервис по одному и тому же ТЗ — получить десять разных сервисов. Попросить обосновать решения — получить вообще не пойми что. Это три.

В разработке очень сложно что-либо спланировать потому, что каждый разработчик уникален. Этих существ можно как-то кластеризовать (вот это junior’ы, это наш золотой запас, а этих уволить), но спланировать их работу невозможно. Можно только угадать с некоторой долей вероятности, а потом в процессе работы палками загонять в сроки (или надеяться на то, что Вася с Петей поработают ночью).

КПД менеджеров и руководителей, пытающихся выстроить стройные и предсказуемые процессы… ожидаемо отрицательный.

Вольница. Разработчик — это драгоценность. Гений. Трепетный одуванчик. Хрустальная человеческая особь, готовая зарыдать при отсутствии печенья на кофепоинте. Пуп Земли, владеющий неисчерпаемыми запасами мнения обо всём, что есть на свете. Наверняка он лучше хирурга оперирует, лучше экономиста управляет банком, лучше космонавта космонавтит и лучше футболиста играет в футбол.

Более эгоцентричных специалистов (разве что лётчики Первой мировой) планета ещё не выпускала. Умножаем на инфантильность поколений 1990+ (а вы думали, программы вам пишут 50-летние аксакалы?), имеем развесёлые будни руководителей и кадровиков, которым надо как-то не расстраивать обидчивого зайку, не слишком давить, но и не давать спуску, вовремя подсовывать морковку и вовремя нежно охаживать по попе ватным прутиком. Иначе зайка убежит на другую лужайку, а софт кому-то писать надо.

Такой подход к трудовым ресурсам порождает отсутствие технического контроля (ты мне не доверяешь? мне? МНЕ?!) и излишнее доверие к. Разработчик не оперирует интересами компании. Разработчик не держит первым приоритетом реальные нужды сервиса. Во главе всего личный интерес. Интересно попробовать новую библиотеку (пусть Петя потом с трудом выпиливает). Интересно придумать оригинальную архитектуру (помните про Вась? вот у них всё оригинальное), чтобы потом все совсем задолбались с этим жить. Интересно убить часы на бесполезные (но громкие и очень интеллектуальные) споры. Интересно поиграть в разработку.

А вот остальное скучно. Потому Вася не пишет документацию. Не пишет тесты. Не использует типовые (aka проверенные) решения. Не читает рабочую почту. Не фиксирует свою деятельность в трекере. Не пишет админки. Не добавляет мониторинги. Не пишет логи. Возможно, и посуду не моет, не знаю — ведь это тоже скучно.

Соберите команду из N таких звёзд и попробуйте эффективно создать эффективный сервис. Если вы не разработчик и не отреагируете вовремя (ну или вам впарят под соусом “очень, очень важно и нужно”), уже через квартал в сервисе будет собственная реализация HTTP (на Rust), микроязык запросов в базу (парсер на Clojure), пара фреймворков для чего-нибудь (все другие фреймворки плохие и неправильные), ну и расхождение с ТЗ примерно на 90 градусов (разработчику виднее).

Кажется очевидным, кто КПД детского сада высоким быть не может.

To be continued.

--

--

Felix IT

Много программирую и много разговариваю.