IT’S JUST GOOD BUISNESS

Дисклеймер

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

Предисловие

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

А ещё в конце статьи есть список литературы.

Ведение

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

• это 10 тысяч часов, которые ты вложил в дело;

• это тренировки и практика в то время, когда другие развлекаются;

• это умение каждый день бить в одну точку;

• это способность верить в свои усилия;

• это железная дисциплина;

• это выбор быть талантливым.

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

Следствием из вышесказанного идет то, что все должны заниматься своим делом… Но по факту это часто совсем не так. Это настолько «не так», что, грубо говоря, «экономисты становятся инженерами» – люди часто не знают, к чему предрасположены и занимаются не тем, чем следует.

И вот, случилось так, что в некоторые сферы можно попасть с минимальными значениями критериев таланта (т.е. без таланта, по сути). Точнее, там переопределяют талант, практически приравнивая к понятию «ментальная гибкость». Оставим за рамками статьи негативные стороны этого приравнивания (а про позитивные вы и так много раз слышали).

Люди, не имеющие таланта, попадают в IT просто потому, что «эта область быстро развивается и требуется много новых специалистов» (о кавычках поговорим позже). Приходится нанимать (как я их люблю называть) «быдлокодеров», «недопрограммистов» и «индокодеров». Ведь талантливых людей мало. А место кем-то надо занять… Также будет затронута потеря таланта (в связи с воздействием окружения) и просто работа «на отвали» в силу некоторых обстоятельств.

Рассмотрим причины подробнее.

Развитие IT

Все постоянно говорят об «экспоненциальных темпах развития технологий», которые создают пустые места, которые нужно заполнять. Однако, это может быть не совсем корректно. Дело в том, что развитие технологического прогресса и появление вакансий могут быть не связаны напрямую (бывает и так). Да, сейчас они коррелируют, но долгосрочный прогноз потребности в кадрах сделать выйдет едва ли и причина тому – автоматизация. Есть 2 основные точки зрения на «будущее кадров»:

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

2. специалистов со временем будет нужно всё меньше, ведь средства автоматизации становятся всё совершеннее, а островок «эксклюзивно человеческих способностей» всё меньше (благодаря ИИ в том числе) – вполне вероятно, что со временем человек может быть полностью заменён почти везде, а там, где останется незаменимым, будут столь высокие требования к компетенции (и низкая потребность в кадрах), что там будет работать не более 1/1000 процента населения, при этом количество таких вакансии будет сокращаться.

Считается, что оба эти сценария возможны: в начале (включая наше время) будет действовать 1 сценарий, а потом он плавно перетечёт во второй. Сложно сказать, что будет происходить с социумом при 2 сценарии, но мир к тому времени уже станет явно другим и, возможно, то, что сейчас кажется самым большим кризисом в истории человечества, на самом деле будет почти безболезненным процессом. Предсказать пока что невозможно. Однако, я отклонился от темы: данная статья призвана разобраться в причинах процессов в настоящем, а не предсказывать будущее.

Раз развитие технологий [относительно] слабо связано с появлением вакансий, то что же стоит за ростом спроса на программистов и других специалистов IT?

Рынок

Именно рынок определяет востребованность той или иной профессии. А вы сомневались? Рынок определяет практически всё, с чем взаимодействует житель развитой/развивающейся страны. Так, как он определяет набор продуктов на прилавках, он определяет и специальности, которые могут заработать, предоставляя те или иные продукты. Технологический прогресс определяет только потенциальный набор ниш рынка, но никак не то, какие ниши действительно образуются и как их займут. Даже самая продвинутая технология (или продвинутый с точки зрения технологий продукт) может не найти потребителя (применения при текущем раскладе товаров/услуг и текущей тенденции) и, как следствие, не образовать востребованности в специалистах, занимающихся изучением/разработкой/производством.

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

Но почему, всё-таки, IT развивается не по пути науки? Ведь не обязательно с любой разработки деньги получать? На самом деле, в большинстве случаев – обязательно, ведь развитием IT занимается, в основном, бизнес.

Бизнес

Вот мы и подошли к этому ключевому понятию. Конечно, с его определениями вы знакомы, как и с его сутью: конечно же, это получение денег. Но если точнее, то суть бизнеса – только получение денег. Бизнесу не нужно ничего, кроме денег. Только вот беда: деньги сами по себе не делаются, из-за чего приходится что-то делать – зарабатывать эти деньги. И вот тут уже каждый выворачивается как может ради прибыли.

Наверное, здорово, когда всё так просто: делаешь все только ради одной цели – прибыли, а всем остальным можешь пренебречь. Общество, да и мир в целом становятся довольно просты. Звучит это абсурдно, но это реальность. Все корпорации, например, работают исключительно по такому принципу. Любая продукция, не приносящая денег, считается побочной и её процент стараются свести к минимуму. Любая же продукция или действия, совершаемые компанией на постоянной основе, «не приносящие» денег на первый взгляд, на самом деле их приносят, только косвенно (или должны принести в будущем). Всё плохое, что компании «не делают», они не делают только чтобы не испортить свой имидж и, как следствие, не потерять деньги. Повторю: главная задача бизнеса – уверенно получать как можно больше денег из всего, из чего только можно.

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

И вот, с бизнес-целями (а точнее, с одной целью) люди, в основном, и начинают IT-стартапы*, которые позже становятся компаниями, а ещё позже – корпорациями – и уже нет никакого способа «слезть с денежной иглы».

Взяв во внимание всё вышесказанное, как вы считаете, каких специалистов нанимают корпорации? Да, конечно же, таких, чтоб как можно больше производили с допустимым уровнем качества при как можно меньших затратах.

Ключевым здесь из этих трёх параметров является допустимый уровень качества (на нём иногда можно заработать очень много за относительно небольшой промежуток времени). Да, среди корпоративных продуктов практически никогда нет 100% качественной продукции (и это не только к IT-индустрии относится). Обычно, порог устанавливается эмпирическим путём. Грубо говоря, требования к качеству (после некоторых проб) выглядят примерно так: «нам нужно, чтобы среди наших пользователей проблемы возникли не более, чем у 1-2%» (конечно, 1-2% — это довольно низкий уровень качества, но для примера сойдёт). Обычно, конечно, критериев качества больше, чем 1 и не все они формулируются именно так, но в целом идея такова: не нужно делать продукт с «военным» качеством, достаточно сделать просто чтобы работало у большинства, а возмущения меньшинства имели минимальное влияние на продаваемость.

Так, с уровнем качества, похоже, разобрались. Однако, кому-то покажется, что разобрались с ним довольно абстрактно и пока не видно здесь непосредственно причины падения качества кадров (в IT, например). Глубинная причина, однако, в основном, кроется именно в допустимом уровне качества. 99.9% проблем, которые вы обнаружите у купленных продуктов (будь то вещи или ПО), были известны производителям при продаже и, вероятно, даже до производства (т.к. есть специальные аналитики, которые предсказывают возможные проблемы конфигураций продукта), а на прилавки продукты попали потому, что их уровень качества оказался допустимым по мнениям производителей. Для гражданских уже никто не делает продукцию без проблем с качеством и даже не факт, что для военных целей продукция выпускается со 100%-качеством (на момент производства т.е. с теми технологиями, которые существовали на тот момент).

С чем напрямую связано качество продукции? Правильно, с количеством денежных средств, вложенных в неё. Если говорить о материальной продукции, то их количество может быть снижено, условно, экономией на материалах и средствах производства. Если говорить о ПО, то тут экономия, аналогично, касается отладки (устранения багов) и самих разработчиков. Экономия на отладке в данном случае сродни экономии на материалах, а экономия на программистах – экономии на средствах производства. Как и полагается, эти две экономии всегда ходят парой (но с разной степенью). По сути, экономия на отладке напрямую влияет на видимое качество получаемой продукции. Это почти тот случай, когда при достаточно продвинутом материале, достаточно простейших средств производства (как, например, для получения куска хлеба, достаточно иметь хлеб – продвинутый материал – и нож – простейшее средство производства). В контексте производства ПО, это звучало бы примерно так: даже плохие программисты при достаточном количестве отладки, смогут произвести качественный продукт (кто знает про процессы Test Driven Design, тот знает). Однако, с этим есть 2 проблемы:

1. ограничения по времени. Бизнес всегда ставит временные рамки на производство той или иной продукции. Нередко случается так, что соблюдение временных рамок оказывается важнее соблюдения допустимого уровня качества (это очень частый случай, кстати). Отладка кода требует гораздо больше времени, чем написание кода. Плохие программисты не смогут написать качественный код и будут добиваться правильной работы ПО отладкой. Значительно увеличатся (в процентном соотношении) объёмы отладки относительно объёмов написанного кода, и, как следствие, очень значительно увеличится количество требуемого на производство программного продукта времени. Это недопустимо, ведь чем скорее будет поступать продукция, тем больше будет получено денег, и у конкурентов будет меньше возможностей потеснить на рынке;

2. внутренние проблемы с качеством. В общем-то, у любой продукции есть видимая и невидимая части. У ПО такое тоже есть, разумеется: человек видит лишь интерфейс и его работу, но всё остальное остаётся за пределами видимости. Горы отладки, конечно, исправят ошибки, но вопрос в том, насколько эффективно эти ошибки будут исправлены. Для понимания проблемы можно привести аналогию: пусть у нас есть 3 города, каждый из которых соединён с другим ровно одной дорогой (все города на равном расстоянии друг от друга), а задача – добраться из города А в город Б. Случилось так, что дорога между городами А и Б неисправна. Можно было бы её починить, однако, задача-то просто добраться из А в Б, следовательно, можно просто поехать через город В и выполнить задачу. Задача выполнена? Выполнена. Ну а неэффективность такого решения никого волновать не будет, пока на постоянной основе не начнут образовываться пробки в город В протяженность с дорогу от А до В. Так вот, проблема 2 заключается в том, что эти пробки (длиной с дорогу от А до В) образовываться всё-таки будут.

«Как же тогда экономить?» — спросите вы. Как найти компромисс, если он вообще есть? На самом деле, этот компромисс есть и его можно чуть ли не Граалем современного IT назвать. Этот Грааль – различные языки программирования и корпоративные библиотеки/фреймворки. Они позволяют экономить и на отладке, и на разработчиках. А что, если я скажу, что они ещё и объёмы производства поднимают? Просто чудо какое-то!

Но на самом деле не всё так хорошо, как может показаться. А самое плохое, что нехорошо оно не для бизнеса, а с «абсолютных» точек зрения (см. мой вариант определения «быдлокодер»). Для кого это плохо? Станет понятно сразу как разберёмся в принципе работы этого «Грааля».

Принцип работы этого «чуда» похож на принцип производства самолёта. При производстве самолёта все его части делаются в разных местах на разных заводах, при чем, и части этих частей производятся так же: не в одном месте. Например, двигатели делаются на одном производстве, металл для крыльев – на другом, сами крылья – на третьем (с использованием результатов работы первых двух производств). На последнее производство свозят все ранее произведённые части и, наконец, собирают самолёт. «Уж не собрался ли он критиковать производство самолётов?» – подумаете вы, а я отвечу: «Нет». Производство самолётов действительно устроено хорошо, но наш «Грааль» доводит этот принцип до абсурда, что, очевидно, плохо. Если держаться той же аналогии, то это выглядело бы примерно так: после сборки самолёт передают на следующее производство, где устанавливают пилота и других членов экипажа, затем передают на производство, где устанавливают тележки, посуду и др., затем передают фирме, которая транспортирует самолёт на исходный аэродром, после чего нанимают специалистов из ещё одной фирмы, которые объясняют пилоту, куда надо лететь и как. Стоит ещё упомянуть, что для работы этих специалистов нужны другие т.к. эти говорят только на Хинди и не могут сами перемещаться по трапу для входа в самолёт (как мы помним, пилот в самолёт уже установлен). Каждую из стадий этого «производства» можно назвать абстракцией и чем дальше от начала, тем больше слоёв абстракции. Как несложно догадаться, в приведённой мной в пример линии производства несколько последних слоёв – явно лишние. Однако, давайте подумаем, что они дают аэропорту, например? А дают они то, что ему самому не надо заботиться о салоне самолёта и экипаже – всё уже сделано – только пользуйся (экипаж, например, автоматически убирает салон до и после полёта). И тут уже не важно, что только для передачи информации пилоту используется цепочка из 5 человек, важно то, что первому в цепочке можно сказать «пусть вылетает», а последний в цепочке передаст пилоту всю инструкцию по управлению самолётом, объяснит на какие координаты лететь и каким маршрутом, и объяснять всё это он будет перед каждым полётом, даже если самолёт летает только между 2 аэропортами (а пилот у самолёта один и тот же – тот, которого установили на производстве). Наверное, уже видно «эффективность» выполнения рейсов?

Именно на сотнях слоёв абстракций и работает «Грааль IT». Один из плюсов для бизнеса был виден ещё в аналогии – меньше забот для программиста и, как следствие, меньшие временные затраты (со стороны программиста) на производство продукта, следствием чего является рост объёмов производства. Но есть и ещё плюс. С помощью абстракций можно упростить любой принцип донельзя (например, весь процесс работы радиоприёмника упростить до «переводит радиоволны в звук»). Таким образом можно кардинально снизить порог входа в ту или иную область (в нашем случае – в IT). А если порог входа снижен, то что? Правильно, можно нанимать более дешёвых специалистов (которых непомерно больше). Можно даже вообще не специалистов нанимать – всё равно они будут работать с чем-то, имеющим с реальными процессами крайне слабую связь.

Таким вот образом можно почти безгранично увеличивать объемы производства, экономить на заботах о качестве (т.к. создатели абстракций «уже позаботились») и производстве (т.к. специалистов требуется меньше и можно нанимать всё больше дешёвых «неспециалистов»). Ultimate combo!

Только вот есть и обратная сторона, а именно – 2 основных проблемы:

1. эффективность выполнения. Да её уже упоминали, но она достойна большего внимания. Как уже говорилось ранее, из-за большого числа слоёв абстракций падает скорость работы ПО (программы начинают работать медленно из-за больших накладных расходов). Думаю, всем уже понятно, как это происходит (если нет ­­– читаем аналогию с самолётом ещё раз). Это, надо сказать, довольно заметный эффект. Причём, слои бывают разные и существуют такие, которые по замедлению десятка других стоят. Однако, существует ещё кое-что. Системы абстракций всегда навязывают какие-то свои правила. Иногда в силу устройства абстрагирующей системы просто нельзя «проехать из города А в Б не через город В, даже если прямая дорога между А и Б исправна». Бывает так, что правила системы абстракций имеют совершенно другие принципы в сравнении с правилами, которые эта система абстрагирует – с таким случаем абстракции получается максимальное замедление (максимальное среди других случаев абстрагирования). Как аналогию можно было бы привести абстрагирование панели управления «классическим автомобилем» (с 3 педалями, механической коробкой передач и т.д.) панелью управления электрогенератором. Невозможно? Ну, вообще-то (при достаточной извращённости), возможно, просто одна команда с пульта генератора может вызвать десяток действий у системы управления автомобилем. Например, «движение вперёд» у автомобиля устроено сложнее вращения ротора генератора. А ещё в панели управления генератором нету, например, команды «движение назад» («вращение ротора в обратную сторону»), из-за чего можно будет ставить автомобиль только на сквозных парковках, ведь он не сможет парковаться ни задом, ни носом (потому что выезжать придётся задом). Это работает и в обратную сторону: чтобы сделать нечто, что с панели управления автомобилем делается легко (смена передачи, например), с панели управления генератором может потребовать десятка команд (просто потому, что панель управления генератором рассчитана на управление генератором, а генератор обычно не имеет аналога коробки передач). И это я ещё не затрагивал особенности представления данных об обстановке вокруг автомобиля на пульте генератора… Вам может показаться, что в IT такого уж точно нет, но, увы, есть. Иногда программисты всё-таки «управляют автомобилем с пульта управления генератором». Например, функциональное программирование (функциональные языки программирования) иногда похоже на это.

2. эффективность реализации. А вот этот пункт можно назвать «business-friendly-вариацией» 2 пункта из предыдущего списка. По сути своей он так же вытекает из снижения порога вхождения, но имеет гораздо больший потенциал для коррекции (о ней позже). Дело в том, что абстрагирование – не панацея от, например, просто неэффективных алгоритмов. Абстракции не могут заставить программиста проектировать качественную архитектуру и писать алгоритмически эффективный код. Очень хороший вопрос: возможно ли каким-то способом заставить программиста писать эффективный код (и нужен ли тогда будет сам программист в нынешнем понимании). Из-за снижения порога входа в IT приходят «специалисты», у которых с алгоритмами и структурами данных (базовыми знаниями, по сути) всё довольно плохо, но это не мешает им работать и получать приличные деньги («быть востребованными на рынке»). Не факт ещё, что эти люди достаточно хорошо знают систему абстракций (язык, фреймворк), с которой работают, чтобы писать оптимальный код хотя бы с точки зрения этого языка/фреймворка, т.к. иногда одна лишняя команда может замедлить выполнение в несколько раз. Ошибки (в смысле неэффективной реализации) «абстрактных программистов» иногда могут стоить дороже ошибок «программистов конкретных». «Иногда» здесь потому, что «конкретные программисты», хоть их и сравнительно мало, часто делают самую ответственную работу (в силу уровня своих знаний), поэтому их ошибки, обычно, дороже ошибок «абстракционистов», но гораздо реже. Однако, «конкретики» не всегда работают над крайне ответственными участками и вот тут ошибка «конкретика», условно, может добавить 1-2 лишних операции, а ошибка «абстракциониста» – 100-200. Конечно, «абстракционисты» бывают разные – есть те, что знают, как делать качественно в рамках возможностей своего инструмента (да и инструменты выбирают умело), но «неспециалистов» гораздо больше (а много и тех, кому просто «не дано» – нет таланта), для которых и работы больше (потому что их работа дешевле, чем работа настоящего специалиста). Также нельзя приуменьшать значение качеств программистов. Если для становления «конкретиком» требуется пройти непростой путь (абы кто не пройдёт, не сможет качественно усвоить материал и, как следствие, не сможет с ним работать), то у «абстракционистов» путь гораздо проще, и пройти его могут многие, следовательно, «фильтрация по качествам» гораздо слабее, из-за чего проходят, например, «лентяи», которым легче подключить к коду целую библиотеку функций (возможно, целый слой абстракций добавить), чем самостоятельно реализовать одну несложную функцию. Алгоритмическая эффективность их кода также вызывает вопросы т.к. тут требуется думать над решением задачи (вероятно, разными подходами к решению), а лентяям над этим думать лень – от них часто можно увидеть решение «влоб» (а такое редко бывает эффективным). В этом месте логично припомнить понятие «ментальная гибкость» (далее – «гибкость»), упоминавшееся ранее. В наше время (и в прогнозах на будущее) его почти приравнивают* к таланту. Я нисколько не отрицаю и даже подчёркиваю важность этого свойства, но не в таком контексте, в каком его нередко преподносят… Ну вы ведь уже догадались, зачем это качество программистов нужно IT-фирмам? В основном, его они ждут от 2, условно, «категорий»: специалистов высокой квалификации и «абстракционистов» среднего и низкого уровней. Людей из 1 категорий (в мире) в десятки тысяч раз меньше, чем из второй, и понятие «гибкость» у них имеет более сложное наполнение, поэтому часто его упоминают в контексте именно 2 категории. Первой категории «гибкость» нужна, например, для рассмотрения альтернативных подходов к решению (при проектировании, например). Второй – для переключения между разными системами абстракций и эффективной работы с ними. Думаю, понятно, что во 2 случае (о котором, на самом деле, и говорят в контексте разработчиков) «гибкость» и близко не синоним понятию «талант». Это требование (нечто необходимое, в отличие от таланта, о котором говорилось в начале), без которого человек «абстракционистом» даже низкого уровня успешно работать не сможет.

Ну вот мы и рассмотрели проблемы этого «Грааля» и, думаю, вы поняли, что для всего кроме бизнеса, это «нечто» уж чем, но «Граалем» точно не является. Ну а для бизнеса нет ничего лучше, и 2 вышеописанные проблемы бизнес обходит не менее «бизнес-идейными» принципами. Так, первую проблему решают просто «горизонтальным масштабированием» – это когда наращиваются вычислительные мощности. Конечно, это «лечение не проблемы, а симптома», но бизнесу важно только чтобы оно работало, а как – не важно (важна лишь прибыль, которую приносят работающие системы)*. Со второй проблемой, может, показаться, разобраться будет сложнее, но нет, тут всё почти так же с одной лишь разницей – «масштабирование вертикальное» (т.е. алгоритмы запаковываются в очередные абстракции – думаете, почему, постоянно появляются новые JS-библиотеки, например?), но это не единственное практикуемое решение. На самом деле, «вертикальное масштабирование» – не самое дешёвое решение – можно проще и дешевле. Делается это с помощью бюрократии введения различных методик разработки и добавления различных остановок на пути deploy (публикации, по сути). Это оказывается куда дешевле и, хоть в полной мере не даёт результатов «вертикального масштабирования», уменьшает процент попадающих в релиз проблем с производительностью до допустимого уровня (вспоминаем допустимый уровень качества). Также эти распорядки решают многие организационные вопросы, по причине чего не могут быть полностью заменены «вертикальным масштабированием». На самом деле, внимание на производительность по заветам бизнеса начинают обращать только тогда, когда её не хватает. Аналитики предсказывают узкие места системы в большинстве случаев заранее, и алгоритмы на этих участках подвергаются большему контролю, а остальные места могут даже быть побоку: пусть хоть пузырьковую сортировку там делают. Нужно сказать, что на данный момент текущего уровня абстракций хватает (новые абстракции в том или ином месте появляются почти каждый день, поэтому правильнее было бы говорить о скорости появления абстракций, которой пока вполне хватает) для получения допустимого уровня качества с использованием довольно несложных методик.

Важно сделать заметку, что некоторые бизнес-практики и за пределами бизнеса имеют жизнь: например, code review, методологии разработки и др., но за пределами бизнеса эти практики не преследуют цели бизнеса, по причине чего работают немного иначе.

Теперь, наверное, вам стало гораздо лучше понятна проблема падения качества программирования (её комплексность, в частности). Выше я говорил о падении качества, как о результате прихода некачественных кадров, но это не всё. Не самом деле, падает качество не только новых (т.к. снижается порог входа), но и старых кадров. Связано это, разумеется, с бизнес-рамками… Даже высококлассного программиста на C++ могут заставить писать на Python для уложения в сроки сдачи проекта (ну и для избавления от «низкоуровневого» кода C++ в кодовой базе, что позволит «неспециалистам» гораздо лучше вливаться в проекты). Да, программист может возмутиться и уйти из фирмы, и, да, это происходит, но не столь часто, как кажется. После C++, Python будет как детский сад после университета, за который ещё и платят неплохо. То есть, например, зарплата та же, работать значительно проще. Неужто, думаете, от подобного часто отказываются? Так происходит деградация специалистов – важное негативное явление, о котором довольно мало упоминаний. Нередко инициатором этой деградации становится сам программист: он видит, что есть язык, на котором можно сделать то же самое (или почти то же самое), но гораздо проще и быстрее, да ещё и выплачивают суммы, сравнимые с з/п программиста на языке более низкого уровня. Разработка проще и быстрее, высокие зарплаты – одни плюсы! Абсолютное большинство людей ставят свой комфорт превыше качества того, что делают (да и вообще превыше всего свой комфорт ставят)...

Политика

Ну вот мы и подошли к ней – «причине всех причин». Разумеется, оставлять политику полностью за рамками данной статьи было бы неправильно.

Хоть, конечно, говорить о политике рискованно, мне придётся о ней упомянуть в чисто научных интересах.

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

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

На этом моменте можно было бы и закончить статью, но мне хотелось бы ещё «пять копеек вставить».

Как считают некоторые люди, капиталистический строй находится не так далеко от «адского» строя и вот почему: в капитализме всё вращается вокруг денет, пренебрегая всем остальным. Пренебрегается то, что за этими деньгами стоит: откуда они пришли и куда идут; пренебрегается объект и субъект намерений: кто деньгами распоряжается и ради чего… Разумеется, «свобода» быть должна, но… сложно сказать, как и в чём она должна проявляться и что вообще считать «свободой» для становления «утопии»… У нас, людей на Земле, всё до сих пор не «по-адски» плохо лишь благодаря существованию институтов морали и права. Пример института морали – религия (она может быть очень разной, но самые базовые вещи везде схожи); пример института права – закон. Для превращения наш мир в ад нам достаточно подчинить эти 2 института деньгам: тот, кто имеет достаточно денег, будет прав всегда (и с моральной точки зрения, и с точки зрения закона - официально и бесповоротно). Think about it.

Послесловие

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

Список литературы

• Карл Маркс “Капитал. Том I.” – https://www.marxists.org/archive/marx/works/download/pdf/Capital-Volume-I.pdf
  

• Robert Martin “The Clean Coder: A Code of Conduct for Professional Programmers” – https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073
  

• Howard Gardner “Frames of Mind: The Theory of Multiple Intelligences” – https://www.goodreads.com/book/show/294035.Frames_of_Mind
  

• Erich Fromm “Man for Himself: An Inquiry Into the Psychology of Ethics” – https://www.goodreads.com/book/show/40718037-man-for-himself
  

• Robin Hanson “Why Does Software Rot?” – https://www.overcomingbias.com/2016/06/why-does-software-rot.html
  

• Martin Fowler “What Is Refactoring” – http://wiki.c2.com/?WhatIsRefactoring
  

• Jonas Söderström “Onceability: The consequence of technology rot” – https://www.inuse.se/blogg/onceability-the-consequence-of-technology-rot-inuseful/