В мире на сегодня накопилось много неприятных вещей и тенденций, о которых почему-то стало неприлично негативно высказываться. Даже фраза появилась: «Вы не понимаете, это другое!» Немалая часть явлений так или иначе связана с ИТ. В рамках проводимого мероприятия «Стань автором, получи футболку!» решил выложить на обсуждение некоторые моменты с комментариями, почему я считаю их вредными, а иногда и опасными.
Поехали.
Криптовалюты и майнинг
Минусы: перевод ценнейших невосполнимых ресурсов на вычисления, не несущие НИКАКОЙ пользы. Сама концепция Proof of Work предполагает, что ценным и продаваемым становится не то, что ты сделал полезного, а насколько задолбался, точнее сколько ты вложил, а потом перевёл полезных ресурсов в некий эфемерный контент, который ни для чего кроме как для вычисления ЧСВ не годится. Хранить – опасно (взломы кошельков и бирж, кражи, которые невозможно «откатить»), использовать, как платёжное средство – долго, геморроойно и дорого. В любой золотой лихорадке первые прибыли идут с продажи лопат. В своё время это вроде не сильно повлияло на достаточность лопат для переселенцев на диком Западе для копания картошки, сейчас же дефицит электроники фигачит по всем отраслям, в том числе и из-за того, что значительная часть этого производства уходит на нужды копателей эфемерного золота. Про Грету и её защиту природы от перегрева писать не буду, и так понятно, что потребление электроэнергии гигаваттами ничего хорошего в данном случае не приносит. Как бы вы не относились к теории глобального потепления.
Плюсы: возможно, некоторый пинок в развитии высокопроизводительных распределённых вычислений, переосмысление эффективности сложившейся финансовой и банковской инфраструктуры. Кстати, оба плюса далеко не исключительная заслуга майнинга.
Итого: требуется включить голос разума и закрыть эту дыру в расходовании ресурсов нашей маленькой планеты, возможно законодательно запретив, возможно сделав такую деятельность чем-то постыдным, признаваемым, как извращение.
Перед следующим тяжёлым явлением, вспомню что-нибудь лайтовое, но раздражающее ежедневно.
Плоский (акриловый, material …) дизайн интерфейсов
Минусы: когда это явление только появилось, оно смотрелось исключительно весело и прикольно. «Смотрите, пацаны, это не надпись, а, внезапно, кнопка! Я догадался, а вы нашли?» Но чем дальше эта зараза, насаждаемая яблочными и не только хипстерами, стала проникать в жизнь, тем хуже становилась юзабельность привычных уже программ и девайсов. Ну, хорошо, на компьютере я провёл мышкой и выцепил момент, когда она, пролетая над элементом, временно мигнула формой курсора. «О, это можно нажать!» Но когда я стою с планшетом или мобилой, а ещё хуже перед банкоматом, гадать «методом тыкания» становится иногда очень даже рискованно. Но попробуй сказать хоть слово в защиту скевоморфизма в интерфейсах, от ярлыка даже не Бумера, а динозавра будет очень тяжело откреститься.
Плюсы: ЧСВ членов закрытой касты дизайнеров есть чем повышать, маскируя action так, чтобы уже совсем никто и никогда не догадался. Свайпы тут в тему, кстати. Нажимать вообще нечего, а action-то есть, но попробуй найди.
Минусы: куча потерянного времени, ошибки в использовании продуктов этих самых плоских дизайнеров.
Итого: осудить и высмеять всем миром. Ввести требование чтобы действия не маскировались и были очевидными. Оставить на задворках для каких-нибудь сект свободных художников.
Похмыкали, привыкли и фиг с ними? Ок, теперь перейдём к вопросу потяжелее.
Стартапы (особенно ИТ стартапы) и экономика стартапов
Как это выглядит для обывателя: гениальные студенты (молодые начинающие ученые) придумали что-то экстраординарное, но на реализацию у них нет средств. Им поначалу никто не верит, но находится прозорливый позитивный спонсор, который в силу своего ума и веры в людей загорается их идеей сделать мир лучше и вкладывает в них свой последний честно заработанный миллион. Дружная команда во главе с гением-лидером не спит ночами, работает, ссорится, мирится но в счастливом финале выкатывает миру новое явление. Деньги, заработанные на внедрении изобретения дают им возможность уехать жить на Багамы до конца дней, получив за их подарок миру помимо заслуженной награды в миллиард ещё и прозвище «единорогов добра».
Как это на самом деле. За очень редкими исключениями. Цинично, и по существу. Хитрый финансист, не желающий, свой, не сильно праведно заработанный капитал вкладывать «в долгую», организовывает структуру, которая рекламируется, как фабрика стартапов. Суть её работы: вы приходите с любой хернёй, которая может никому и не нужна, показываете, как это можно впарить обывателю-дураку, верящему в чудо/банкиру недоумку/спекулянту на таких же недоумках. Набираете рабов, которые за призрачную морковку на горизонте с надписью «доля в прибыли» в кратчайшие сроки и в адских условиях кодят/пилят/паяют неведомую фигню. Если это кодинг, то обязательно нужны все внешние карго-культовые атрибуты типа Аджайла/Скрама, и портрета Джобса во всю стену, закрывающего дыры и отвалившуюся штукатурку. Обязателен внешний антураж в виде выступлений на технологических конференциях для таких же рабов, которые в результате начинают думать, что прогрессивные стартаперы это они и есть, а не тот ушлый манагер, который их продал организатору фабрики стартапов. Т.к. рабы далеко не безграмотны и чаще всего реально владеют определенными технологиями, им всегда есть о чем поговорить. Плюс спонсором этого шоу обычно является тот самый владелец фабрики. В силу закона больших чисел 99% таких стартаперских затей проваливаются, не успев сделать вообще ничего, но неплохо собрав денег, в том числе и со сторонних инвесторов-лохов «в рост и перспективу». Часть на каком-то этапе обязательно палится на откровенном кидалове инвесторов, тогда это объявляется, как очищение святых прогрессивных рядов от недобросовестных конкурентов. Если сварганенная фигня может быть хоть как-то применена на практике, компанию начинают судорожно и с массой подтасовок готовить к продаже на бирже, что торжественно обзывается «выходом на IPO», и как-то до сих пор прокатывает с массой пустышек. Они же, при стабильно убыточной работе, становятся далее предметом торга и дальнейших спекуляций для тех, кого не пустили «в нефть/металлы». В плюсе: организатор фабрики, наёмный или добровольный погонщик рабов, кстати, часто искренне считающий себя инноватором, изобретателем и идеологом этого конкретного стартапа. В минусе – все остальные. Что на выходе: сгоревшие разработчики, которые вполне могли принести реальную пользу, работая в другом нормальном месте, создавая хоть что-то ценное. Отвратительного качества продукты и сервисы, к которым по-хорошему нужно сразу прикладывать многомиллионные иски за несоответствие заявленным качествам, но толератно-тактичное общество это жрёт, приговаривая «мы за прогресс, надо потерпеть, дальше будет лучше, но не сразу». Самое плохое: стиль работы на выгорание становится примером для многих работодателей (вот, они же смогли?) и, что ещё хуже, возводится в культ: «только так работают профессионалы». Для нормальных профи на своём месте становится упрёком: вы не горите на работе. Колоссальный отток капиталов, которые могли финансировать длинные ценные проекты в эту короткую спекулятивную кухню. Кончится это наверняка пузырём, как в своё время доткомы. Второй существенный минус: появляется желание поиграть в стартап. Как у бизнеса, который хочет казаться прогрессивным, финансируя неведомо что, так и у не прибитых никуда разрабов и затейников с менеджерской хваткой. Пока пилится продукт зарплаты могут быть очень даже неплохими. На выходе в лучшем случае велосипед среднего качества, в обычном – «не взлетело, это был риск, закрываем».
Итого: пора заканчивать толерантно относиться к обману потребителя и инвестора и перестать воспевать «феномен стартапов». Это просто создание ещё одного рынка пустышек, которое добром не кончится.
Методология разработки AGILE. Продуктовый подход в инсорсе
Сейчас будет конкретно подгорать у тех, кто годами пилит для бизнеса его инструменты, сидя при этом на окладе.
Оговорюсь сразу, что в принципе любая методология имеет право на жизнь и применение, если она к месту, ресурсам, задаче и времени. Но вот то, что происходит сейчас, меня конкретно печалит. Т.к. часто приходится наблюдать со стороны, как немалые суммы бизнес тратит впустую.
Уже долгие годы замечаю интересную тенденцию, что те 1С-ники, с которыми меня столкнула работа, делятся весьма чётко на душных мудаков тихушников и классных спецов нормальных людей по одному простому признаку: постоянные они сотрудники или наёмные из внешней компании. Как-то вот не складывается работа на окладе в больших компаниях у инициативных и порядочных (это важно!) специалистов-разработчиков 1С. Уходят в аутсорс. Достоверно не знаю, как обстоит дело у разработчиков на других платформах и языках, но не думаю, что разница принципиальна.
С течением времени и, если можно так выразиться, с выкристаллизацией такого отвратительного понятия и подхода, как Продукт (с большой буквы) ясность появилась. Попробую показать ход мысли.
У работника по найму в разработке на окладе всегда есть периоды, когда загрузка падает до минимальной. У более-менее людей с совестью (ого, совесть в 21-м веке) это вызывает некоторый дискомфорт. Деньги идут, отдачи нет. У людей, которые не сильно профессиональны, но существенно менее совестливы такие периоды вызывают дискомфорт тоже, но по другой причине. Появляется страх сокращения, а идти особо и некуда, т.к. квалификация невысока. Естественное разделение. Вот оно откуда.. Ушлые менеджеры, которые чаще всего совестью не обременены, нашли выход, как убрать дискомфорт и угрозу своему существованию и как снять напряжение у оставшихся, не сбежавших «специалистов». В инсорсе в результате нехитрых манипуляций сознанием Заказчика, т.е. владельца компании, тоже вводится и насаждается понятие Продукта. Бинго! Вместо выполнения конечной задачи с конечными сроками теперь можно бесконечно долго пилить одно и тоже, навешивая не всегда нужную функциональность, меняя технологии (все сейчас в контейнерах и на S3, нам тоже критически важно туда и именно сейчас, кто опоздал, тот проиграл!). Бизнесу не надо показывать окончательные сроки, боль дедлайна размазывается на мелкие боли. Защищать стоимость Проекта не надо. Проекта же нет. Главная задача этого подхода: исчезновение даты окончания разработки и передачи результата в эксплуатацию. Как-нибудь сами, навсегда. Разработка становится вечной, зарплата всегда оправдана. Выгода вторичная: баги и косяки всегда имеют обоснование: мы пилили фичу срочно, в следующем спринте исправим. Минусы: разработка ведётся оставшимися ресурсами, которые приняли такую ситуацию, как должное. Многим их них стыдно, но они никогда в этом не признаются: «Это же мэйнстрим, все так работают, мы прогрессивные Скрумщики, а не какие-то замшелые ватерфоллисты.» Бизнес видит, что концов уже не найти, остальные коллеги по несчастью смирились тоже, управленческий строй поддерживает всячески миф о прогрессивности и эффективности Продуктового подхода. Гибкие методологии разработки тут подходят идеально, их распиаренная популярность великолепно закрывает вопрос совестью и сомнения у того, кто это банкет транжирства оплачивает. На выходе: стоимость владения такими инструментами в разы, иногда на порядки выше, чем покупка немодного готового адаптированного решения. Инструмент (Продукт) никогда не работает так, как это нужно заказчику, эффективность низкая, а значит и себестоимость того, чем бизнес это безобразие оплачивает тоже растёт.
Итого. Я предполагаю, что пора честно наконец признать: Продуктовый подход и гибкие методологии разработки не являются волшебным стандартом, который надо проталкивать везде. В большинстве случаев от Продуктового подхода вреда гораздо больше, чем пользы.
И последнее на сегодня, DevOps-ерское безумие
Плюсы: иногда это работает. Как великолепно описано в книге «корпорация Феникс» работать с мудаками нельзя. Если на стороне разработки сидят ленивые ортодоксальные ботаны, которым нормально ввалить в файловую структуру миллион файлов: «а что такого, код же красивый», а на стороне инфраструктуры сидят динозавры, накатывающие ось на железо, да ещё и вручную через GUI, то явно что-то идёт не так.
Нормальное конструктивное взаимодействие, к которому пришли профессионалы, досконально знающие свой вопрос и понимающие основы смежных тем, там привело к отличному результату не столько из-за изменения подхода в целом, сколько из-за роста понимания всеми участниками процесса всей цепочки доставки и выполнения конечного результата их работы.
Минусы. Это не то, что в жизни. Сейчас мне скажут, что это же и есть DevOps! В книге всё же расписано, и непрерывное тестирование, и непрерывная доставка изменений, и подготовка сред выполнения, как кода самими разработчиками. Все разбираются досконально во всём, все такие лапочки, что только порадоваться можно. А когда задолбало покупать серваки стойками, то все дружно ушли в облако и настало счастье. Фигак и занавес.
Так вот это оптимистичное описание ничего общего не имеет с реальной жизнью и с тем, что нынче называют DevOps подходом. На практике обычно появляется кучка (или один-два) разрабов, которые узнали, что «DevOps-ам много платят» и они решили по верхам (иногда и глубоко) пройтись по модным темам, типа K8S, Helm, Terraform. Даже ничего не понимая, и не считая нужным понимать, что базы не в воздухе размещены и живут, а на дисках, не по воздуху приходят, а по сети, не в вакуум, а на вычислительную ноду, которая будь хоть сто раз вложенно виртуализирована, один чёрт работает на процессоре с какой-то своей специфичной архитектурой и особенностями. Что тупо добавить памяти не всегда приводит к росту скорости. (Про NUMA они наверняка вообще никогда не слышали.)
Эти «девопсы» начинают неплохо, пока всё живёт по-старому, на настроенной специалистами платформе, потом потихоньку начинают городить дичь, перестают быть вменяемыми при общении с другими профессионалами и в случае неизбежных факапов всегда находят на что свалить сорванный SLA. На тяжёлое наследие легаси, разумеется. И старое железо, от которого пора избавиться..
В чем же проблема? А она в том, что нельзя любого «многостаночника» автоматически называть девопосом, на девопса нельзя выучиться «с нуля». Должен быть багаж и опыт за спиной, и желательно не узко прикладной. Нельзя такому «девопсу» отдавать безраздельную власть над проектом и уж тем более над инфраструктурой. Специалисты сетевики, как ни странно, очень даже нужны. Как и системные инженеры, и DBA со знанием особенностей СУБД. Надо перестать платить конские деньги просто за знание модных технологий и стеков, начать считать TCO и понимать, что подход «смасштабируемся, если что, горизонтально» чаще всего изначально неправильный. В общем, тут не столько про вред DevOps, а про вред модных шарлатанов. И недобросовестную эксплуатацию модного термина. Но так недалеко и до того, что рациональные вещи скоро тоже будут хейтить только за то, про них какой-то реальный адекватный DevOps положительно высказался.
Итого: не надо «всё в девопс». Чаще всего вам это не нужно, либо не по карману. А то, что по карману не является тем, чем названо.
Ну и самое последнее, про «все в облака!». Хоть здесь наконец-то мировой разум немного пришёл в себя, вывесил лозунг «Cloud repatriation!» и пошёл верным путём, в гибриды.
А что Вы считаете вредным и требующим адекватной и справедливой реакции общества?
Добра всем, жить своим умом, разума и процветания!
