Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно

— Люди не из индустрии вечно не понимают программистов: что они там такое сложное делают, если видно только две кнопки? Что за непонятные слова говорят? Почему так много получают?

Вместе с парнями из подкаста «Мы обречены» решили с этим разобраться и запустили совместную рубрику, где будем объяснять, почему в разработке всё так сложно. А для тех, кто любит читать, а не слушать, парни написали эту статью.

Знаете такое чувство, когда вдруг понял, что работаешь уже целый год, хотя идея проекта была простой? Вас пять разработчиков, четыре тестера, проджект и продакт-менеджеры. Ты смотришь на получившееся ПО, и думаешь — ну что мы могли так долго делать? Пять основных фич, три десятка маленьких — нормальному инженеру на неделю работы.

Я часто ловлю себя на таком. Но дальше происходит одно и то же. Начинаю разматывать это в голове, вспоминать, какая работа была проделана. Какие нюансы есть в процессе, который мы тут автоматизируем. Какие, казалось бы, нерешаемые проблемы мы разрулили. И чем больше думаю, тем больше убеждаюсь — да то, что мы вообще дошли до этого этапа, это уже небольшое чудо.

С программным обеспечением всегда так. На поверхности кажется, что мы делаем простые штуки. Но на самом деле — оно невероятно сложное. Проблема в том, что сложность станет видна, только когда ты погрузишься во все технические нюансы.

Нам всем приходится работать с не-инженерами, для них вся сложность существует только на наших словах — другого способа осознать её у них просто нет. И, конечно же, нам вечно не верят. Как будто нам не хватает собственного синдрома самозванца?!

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

— Почему ты всегда всё делаешь в два раза дольше, чем обещаешь?

— Потому что создатели Agile не верят, что можно делать что-то больше недели. Вот и говорю, во что поверят.

А если серьёзно: детали не видны изначально, всегда кажется, что сделать надо немного, и получится быстро. Уже в процессе работы натыкаешься на кучу нюансов, иногда, пока делаешь задачу, требования меняются. Пока работаешь ты — над тем же проектом работают ещё пять человек, и часто их изменения означают дополнительную работу для тебя.

Бывает, что в процессе работы вообще понимаешь — задачу выполнить невозможно. Но самая жесть в том, что очень часто ты понимаешь — работы над задачей вагон, но если скажешь это менеджеру, он будет требовать, чтобы ты объяснил ему, почему. А это ещё одна гигантская задача — объяснить так, чтобы было понятно и не выглядело, как отмазка.

— Зачем ты мудришь?! Сделай, чтобы просто работало!

— Я могу. Но ты же потом придёшь, и скажешь, что открыл её с калькулятора, и там верстка поехала — работа не выполнена.

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

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

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

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

Это так работает, даже когда вас всего двое. Когда у тебя на рынке продукт, которым пользуется миллион человек — и каждый из них опосредованно участвует в выработке требований — можешь вообще забыть об идее, что у тебя в кодовой базе будет хоть что-то устойчивое. Миллион пользователей, аналитики и продакты генерируют идеи со скоростью света. Всё это надо воплощать так, чтобы не повалилась обратная совместимость. Чтобы все новые идеи заработали, а в старых всё осталось как было, хотя код старых и новых идей связан между собой. И чтобы поправить в одном месте, придётся затронуть другое.

Разработчики думают наперёд, и это удорожает разработку в разы. Но если бы не думали, подорожало бы в десятки десятков раз.

— Почему вы просто не возьмёте и не придумаете уже один нормальный язык, на котором всё будет работать?

— А почему люди не начнут говорить на одном языке?

А если серьёзно: у нас тысячи классов задач. Разные языки по-разному подходят под разные задачи. У нас миллионы очень разных разработчиков. Часть из них отлично подойдёт, чтобы делать простенькие приложения, а часть — чтобы пилить рокет саенс. Вторым нужен очень сложный язык, иначе получится непроизводительно. А первые такой просто не смогут освоить. А нужны-то и те и другие!

Есть причины и поглубже. Наши языки программирования отлично подходят, чтобы описывать формальные системы вроде математических уравнений. Процессы людей и их делишек они описывают очень плохо. Потому что языки программирования — сами по себе формальная система, причём она куда беднее, чем те же человеческие языки. Ненавижу эту отвратительную метафору, но программирование условного Doom на C++ — это натягивание совы на глобус.

В языке нет терминов и понятий воюющих между собой живых существ. Машина будет знать только то, что внесли в неё программисты. Если пуля врезается в стену, она останавливается. А если стена резиновая, то отскакивает. А если пластиковая, прошибает насквозь. Сколько возможных материалов, толщин и вообще конфигураций стен вообще может существовать? Сколько из них должны описать мы? Мы пишем облегчённое подобие мировой физики, чтобы не описывать все кейсы вручную, но даже это подобие — бесконечно сложное. Если вы хотите, чтобы у вас была стрелялка, похожая на реальность — увольняйте программистов, и нанимайте Богов. Эти ребята потянут физику такого качества.

— Опять баги! Почему вы не можете писать без них, неучи?

— Баги — это чтобы бизнес не подумал, что сможет обойтись без нас.

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

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

У большинства из нас по несколько десятков разных проектов за карьеру, мы, конечно, стараемся вникать в предметную область, но никогда не сможем гарантировать, что действительно её понимаем. А те, кто её понимают, никогда не смогут прочитать наш код. Это создаёт разрыв, и чем сложнее процесс, тем он больше. Мы бы может и учли большую часть возможных ошибок, если бы до конца понимали, что именно делаем. Но мы ведь не понимаем — для этого нам надо быть большими экспертами в двух несвязанных областях сразу. А жизнь слишком коротка, чтобы даже одно дело изучить как следует.

— Какой ещё новый язык? Какой ещё современный фреймворк? Нам не до игрушек! Почему не можете просто писать на чём есть?

— Работа должна приносить удовольствие. Мы хотим поиграть в игрушки.

А если серьёзно: все новые инструменты появляются только для того, чтобы решить проблему, которая не решена в старых. Мы боремся за десятые доли процента оптимизации, и в целом, это вообще единственный способ борьбы с хаосом роста требований и индустрии. Мы отвечаем этому хаосу мощью и универсальностью своих новых инструментов. И на дистанции видим — подход работает. Чтобы сделать простое десктопное окно на старом WinApi, надо было написать сто строк кода. А сейчас — одну.

Индустрия растёт и развивается бешеными темпами, у нас появляется куча инструментов, которые, по идее, должны облегчить наш труд. Так вот, даже чтобы просто неплохо знать все инструменты, которые тебе нужны в работе, ты уже должен где-то отыскать 40 часов в сутки. У нас их конечно нет, поэтому можете быть уверены — ни один из ваших программистов не знает до конца даже те штуки, которые использует, пока делает те штуки, которые вы ему сказали. Пропускная способность человеческих мозгов сейчас недостаточно хороша, чтобы поддерживать возможность быть хорошим программистом. Наши мозги не подходят для этой работы, но другого варианта у нас тоже нет.

— Почему программисты так много получают? Ходите, кофе пьёте! За что вам платят!?

— Потому что можем.

Но если серьёзно: потому что простые вещи, которые мы так долго и так плохо делаем, автоматизируют человечеству процессы, которые стоят намного дороже, чем отделы программистов. Это просто экономика. Даже 1С бухгалтерия автоматизировала человеческий труд на многие миллионы долларов.

А кроме автоматизации мы ещё делаем вещи, которыми люди буквально живут.

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

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

Мы любим жаловаться, что джуны ничего не знают, но за этим «ничего» уже есть гигантское количество знаний и нейронных связей. До своей первой работы я год корпел над консольными шахматами, которые писал, чтобы изучить С++. Там было несколько тысяч строк кода, они работали каким-то чудом, потому что страшно толстого талмуда «Программирование на языке С++» не хватило, чтобы ответить даже на малую часть моих вопросов, как делать. Форумы, стековерфлоу, разные версии компилятора, стандарты, разные IDE — те дни были большим мучением для моих мозгов.

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

Мы все проходим большой и сложный путь и, если отбросить всю иронию, делаем реально сложные дорогие вещи. Если форма делается две недели, а не день, значит были причины. И обывательской интуиции не всегда хватает, чтобы их понять.