Эффективный менеджмент в IT и его последствия

Предисловие

Речь пойдёт об одной из самых наболевших для меня (и, уверен, не только меня) тем в компьютерной области. О том, почему та область, которой я посвятил чуть ли не всю жизнь, начиная лет с 6-7, теперь уже вряд ли когда-то будет для меня основным источником дохода. В этом тексте я не преследую скрытых целей — поумничать, возвыситься над кем-то, оклеветать кого-то и т. п. Единственная его цель — в исчерпывающей и максимально доходчивой форме передать суть проблемы, с которой я лично столкнулся и в которой я вижу угрозу для себя. Голословные утверждения в духе «ты не прав» или «ты ничего не понимаешь» в качестве контраргументов не годятся, отрицание проблемы никак не поможет её решить.

DESCRIPTION

Современные подходы в IT построены на вере в возможность существования некоторого набора шаблонных, но при этом универсальных методик, с помощью которых можно одинаково быстро и качественно решать любые задачи, независимо от нюансов задач и субъективного удобства методик для конкретного разработчика. То есть, методы решения задач фиксируются, вместо того, чтобы подгоняться под обстоятельства. Однажды мне дали на доработку сайт-одностраничник, сделанный «на Bitrix», который фактически состоял из index.html, одного JS-файла и таблицы стилей, а Bitrix, видимо, стоял для успокоения заказчика, который захотел «сайт на Bitrix», потому, что слышал, что это круто. Когда я смотрю на модные фреймворки, методики и прочие best practices, и то, с каким фанатизмом эффективные менеджеры пытаются в них впихнуть невпихуемое — всю разработку со всей её нешаблонностью, будучи уверенными, что лучше специалиста знают, как надо, превращая это в обязаловку фактически под угрозой для специалиста остаться без работы в случае его несогласия, у меня возникает ассоциация с фразой «прокрустово ложе».
Не это ли мы наблюдаем в современном IT? Только здесь ради прихотей дефективных менеджеров вытягиваются размеры, сложность и время разработки программы (включая время на изучение новых фреймворков) ради того, чтобы она была сделана на модном фреймворке по модным методикам, в ущерб её простоте и надёжности, а разработчику вместо рук и ног обрубается возможность пользоваться своими инженерными способностями, что тоже делает его в некотором смысле инвалидом. Теперь от разработчика больше не требуются его главные сильные стороны, которые раньше всегда его выручали — изобретательность и инженерное мышление, позволяющие находить наиболее удачные варианты реализации и просчитывать в уме её детали. Зато требуется идеальная память, повышенные работоспособность и стрессоустойчивость, чтобы бесконечно изучать новомодные фреймворки и методики, умение и желание бесконечно подстраиваться под них, бороться с их ограничениями и непродуманностью, делать костыли и кастомную логику там, где требуемая функциональность в их прокрустово ложе не вписывается. Теперь программисту можно похоронить все свои знания, умения и наработки, которые он нарабатывал лет 10-20. В реалиях современного IT они ему уже мало чем помогут, а за их использование его будет судить святая инквизиция в лице начальства и коллег. Как это он, инакомыслящий вероотступник, посмел сделать что-то по-своему? Неужели он возомнил себя умнее всех? И как же теперь будут разбираться в его коде другие разработчики, привыкшие делать всё по шаблонам и шарахающиеся от всего, что сделано не по ним? Вы не хотите идти в ногу с цивилизованным миром и использовать современные фреймворки? Вам они неудобны и только отнимают время и нервы? Значит, вы плохой разработчик, вы нам не подходите, увольняйтесь.

Конечная цель всего этого — низвести разработчика до уровня мелкого винтика в производственной системе ради стабильности бизнеса, сделав его легко и быстро заменяемым. Даже если это даётся ценой качества конечного результата. Вот реальная причина популярности большинства популярных фреймворков и методик, а не их техническое совершенство или какие-то заложенные в них гениальные идеи. «Лучшими» эти практики являются лишь для бизнеса, для разработчика же лучше использовать свои наработки и иметь дело с тем, что он знает досконально, чем вызубрить кучу фреймворков, не вызывающих доверия в плане безопасности ввиду огромных объёмов их кода и малореальности его изучения для одного человека (а без этого можно допустить уязвимость из-за незнания, какие механизмы безопасности реализованы во фреймворке и как). Так какой мне интерес их изучать, если я могу те же задачи за то же самое время (если не быстрее) решить без них, с использованием своих наработок, библиотек, фреймворков и т. д., при этом быть уверенным в качестве результата? Или мои интересы никого не интересуют, ведь «проблемы индейцев вождя не волнуют»? Ни одного вразумительного ответа на этот вопрос мне до сих пор никто не дал.

Я не против готовых решений и фреймворков как таковых. Я против бюрократизации разработки (когда «шашечки» становятся важнее, чем ехать), навязывания разработчику методов и инструментов выполнения его работы, использования фреймворков как «чёрных ящиков» (без понимания, что внутри них), бесконечного изучения новых модных фреймворков и языков, которые всё равно через несколько лет потеряют актуальность, вместо того, чтобы вкладывать свои время и усилия в то, что никуда со временем не денется. Но больше всего я против отрицания понятия «квалифицированный труд», отношения к разработчику как к бездушному, легко заменяемому трудовому ресурсу, а не квалифицированному специалисту, а к его труду как к чисто механическому. Есть люди, чей мозг лучше заточен под эффективное применение готовых решений, а есть те, у кого мозг заточен под создание чего-то нового в нетипичных ситуациях, когда подходящих готовых решений нет. И те, и другие одинаково нуждаются в стабильном доходе, но при этом вторые почему-то едва ли востребованы и вообще будто стали считаться лишними.

Свои библиотеки и микрофреймворки, которые я писал для себя, выполнены в соответствии с принципом KISS, то есть максимально простым и надёжным способом, с минимумом зависимостей от чего бы то ни было: дополнительного софта, каких-то пакетных менеджеров, Docker — в общем, всего того, что не обязано быть в системе из коробки и в чём конечный пользователь не обязан разбираться. Языки программирования я предпочитаю такие же. Это значительно снижает вероятность багов, повышает общую надёжность системы и облегчает отладку (без поисковиков и StackOverflow). А главное — экономит время, позволяет в процессе разработки освободить ресурсы своего мозга и направить их полностью на задачу, так как не требуется учитывать множество нюансов языка и фреймворка, соблюдать тщательно вызубренные сотни правил и формальностей (вплоть до требований к количеству комментариев в коде), боясь что-нибудь не учесть и чувствуя себя как на минном поле. Число Миллера, примерно соответствующее объёму кратковременной памяти нашего мозга, не такое уж и большое и в среднем равно 7 ± 2 элементам. Вместо того, чтобы думать обо всех этих формальностях, куда полезнее думать о более важном — что нужно учесть, чтобы не допустить багов, какие фрагменты кода в каких ситуациях как себя могут повести и могут ли привести к уязвимостям. А ещё я всегда исхожу из того, что, решая проблему, надо при этом не создавать другие. Если решая проблему ты создал другую (которую потом тоже придётся решать, тебе или кому-то), то суммарно ты ничего не улучшил. Эх, если бы в IT все этим руководствовались…

Отдельно стоит отметить явную избыточность слоёв абстракции в современном софте, к которой привела чрезмерная увлечённость фреймворками и готовыми решениями (которые в свою очередь тоже используют готовые решения, и так далее по рекурсии). Когда программа делает то же самое, что её аналог 15-летней давности, но при этом жрёт в десятки раз больше. Наглядный пример: мой Atom с плагинами занимает 431 МБ памяти, тогда как Geany (тоже с плагинами) — 7 МБ. Всё, чего мне не хватает в Geany — это несколько курсоров и сниппеты, как в Atom, в остальном же эти редакторы не сильно отличаются по функциональности. Или какой-нибудь современный интернет-магазин, у которого одна страница прогружается несколько секунд (около 750 запросов), требует процессор минимум уровня Core i3 для более-менее приемлемой производительности и хотя бы гигабайт свободной памяти. Тогда как раньше того же самого хватало для запуска нескольких экземпляров какой-нибудь 3D-игры. Если сравнивать, как было и как стало, то это можно назвать разве что усложнением, но не прогрессом.

Итак, что мы видим в итоге? Во сколько раз современные фреймворки и методики упростили разработку, во столько же раз и усложнили её, вынуждая бороться с их ограничениями и сложностью. Во сколько раз увеличились объёмы памяти, производительность современного железа и скорости передачи данных, во столько же раз уменьшился и КПД современного программного обеспечения, компенсировав улучшения в железе. А по итогу мы решаем те же задачи и за то же время, что и 20 лет назад, только другими путями. Похоже на «Тришкин кафтан», о котором Крылов писал более 200 лет назад, не так ли? Но мало кто это замечает, все привыкли и уже мало кому это кажется чем-то ненормальным. Сюжет антиутопической комедии «Идиократия» уже не кажется таким смешным и всё более становится похожим на пророчество…

SEE ALSO

• Почему увольняют самых опытных? Потому что они слишком умные. Тейлоризм 21-го века
• Не учите фреймворки, учите архитектуру
• Микросервисы — отчуждение от результатов труда
• Почему я ненавижу фреймворки
• Тьюринговская трясина
• В софте все плохо и становится еще хуже
• Атака на зависимости