Почему в мире так много отстойного ПО +15


AliExpress RU&CIS

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

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

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


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

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

И наконец, когда разработчики достигают определённого порога навыков, они пересекают его
и попадают в третью категорию. В категорию, где каждый достиг такого высокого уровня компетентности (относительно решаемой ими задачи), что дальнейший личный рост минимально отразится на конечном продукте. Например, любой случайно выбранный инженер из Google может создать CRUD-приложение столь же качественно, как и Джефф Дин.



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

Однако между нами и этой утопией стоят две проблемы.

Во-первых, количество разработчиков из третьей категории чрезвычайно мало по сравнению со второй категорией. Программирование «легко изучить, но сложно освоить». Миллионы людей могут написать функционирующий скрипт, но очень немногие мастерски освоили искусство проектирования ПО. К тому же, не существует никаких препятствий к попаданию в отрасль разработки ПО — для программистов нет аналога Американской медицинской ассоциации или Международной ассоциации юристов. Неудивительно, что в ней гораздо больше людей с начальной и средней компетентностью по сравнению с количеством компетентных специалистов.

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

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

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



Можно впасть в заблуждение, что подобная ситуация естественна для всего мира и всех профессионалов. Но на самом деле это не так.

Существует множество должностей, требующих серьёзного обучения, но относящихся к категории «простых в освоении». Это профессии наподобие водителя такси, строителя или бармена. В таких профессиях есть большая доля работников, достигших категории высокой компетентности, а дальнейшее совершенствование навыков практически не приносит никакой выгоды.

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

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



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

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

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

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



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

Кроме того, в нём рассматривается только та часть уравнения, которая относится к разработчикам. Менеджеры и CEO, не дающие разработчикам достаточно времени для создания безупречного ПО и предпочитающие выпустить нечто «сносное» — ещё одна серьёзная причина проблемы, которую мы исследуем в другой статье.

image




Комментарии (27):

  1. aml
    /#23043248

    Все так. Читать надо вместе со статьей про Fizz Buzz.

  2. LuchS-lynx
    /#23043362 / +1

    Подобная некомпетентность ни за что бы не сошла с рук в других инженерных дисциплинах. Мы бы ни на каких условиях не смирились бы с мостами, имеющими столько же багов, что и среднестатистическая программная система.
    Боюсь это идеалистическое заблуждение, и, самое страшное, что сходит с рук. Почему так происходит? Тому есть множество причин, начиная от человеческого фактора и неадекватности системы управления и, заканчивая экономикой производства… Не нужно идеализировать мир, вокруг единицы идеальных решений и многие миллионы «приемлемых»

    • novoselov
      /#23043548 / +1

      Некорректное сравнение с мостами, чтобы построить мост вам нужно (очень упрощенно):


      • посчитать расстояние между берегами
      • провести разведку грунта
      • рассчитать нагрузку на опоры и повесить знак на въезде "не больше 5 тонн"
      • при этом за проектирования, строительство, проверки отвечает больше 100 людей различной квалификации

      А теперь представьте что заказчик:


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

      • LuchS-lynx
        /#23043816

        при этом в зависимости от загрузки мост должен превращаться из подвесного в деревянный, а при высоких нагрузках в вантовый

        Я изучил Ваш аргументированный выпад в стилистике «гордость наизнанку» и принял решение предложить Вам поучаствовать в моем некоммерческом проекте, который я пишу для инженегров ПТО на связке Excel+VBA, распространяемой бесплатно, в качестве тестера хотя бы разово. Вы так творчески подходите к вопросу проблем и ошибок, что было бы непозволительной роскошью не предложить Вам сотрудничество.

        • novoselov
          /#23045526

          При чем тут гордость? Я про равнозначную постановку задачи. Мост это массовый стандартный продукт. Вы же не удивляетесь тому что не падают панельные многоэтажки? (вообще-то падают)
          При создании приложения вы можете не знать предметной области, не иметь опыт с используемыми в проекте технологиями, писать алгоритмы с нуля и в единственном экземпляре, изучать необходимый функционал в процессе написания и использования. Представьте что было бы если бы инженеры работали в таких же условиях?
          P.S. спасибо за приглашение, pet project у меня есть

          • LuchS-lynx
            /#23045722

            Про гордость наоборот - это была отсылка к Эрику Берну "Игры в которые играют люди". По-этому я предложил сменить игру ;) и перевести диалог в конструктивное русло, ибо эта статья эмоции, но понимает правильные вопросы, однако причин, по которому так происходит очень много. У меня, так же как и у автора, нет ответов, как все исправить. Я регулярно вижу это вокруг, я даже написал статью на Хабре об этом и.... не опубликовал ее, потому что в основе проблем лежат общественные законы и предпосылки которых лично мне не дано изменить... наверное

            • novoselov
              /#23046850

              Для тех кто как и я не читал эту книгу, гордостью наизнанку это когда «мои несчастья лучше ваших». Не совсем то что я имел в виду, но пусть будет так.
              В статье сравниваются различные сферы:


              • строительство, с длительной историей развития и высоким импакт фактором на жизни людей, где результат не меняется после реализации
              • разработка, которой не более 30 лет, где падение приложения на неделю не приведет к человеческим жертвам

              И да, я описал только часть из целого вороха проблем, просто их никто не решает, потому что всем нужен быстрый продукт, а не правильный процесс.
              Хотите конструктивное предложение, посмотрите на инженерные практики под другим углом и попробуйте перенести их в программирование. В разработке нужны стандартные строительные блоки разного размера и сложности, качество кода должно регулироваться ГОСТами быть проверяемым алгоритмически, образование должно быть доступным, более структурированным и последовательным.

      • thatsme
        /#23045550

        Раскажите мне, почему MS Teams, — говно? Я не просил делать подобного мостра для коммандных коммуникаций. Отвратительный интерфейс. Вечное глюкалово. Невозможность удалить галлерею или всю область презентации целиком увеличить на весь экран. А ещё это тормозной мега-комбайн.
        Сорри за ненормативку. Прорвало…

    • sshikov
      /#23043626

      Да что уж там, я позавчера смотрел тест набора инструмента китайского. У молотка отвалилась рукоятка после попытки забить первый или второй гвоздь. Рукоятка оказалась из трубки, диаметром миллиметров 10. На пассатижах чехлы на рукоятках прокручивались при сжатии. При попытке откусить разумного размера гвоздь пассатижи перекрутило, и они стали непригодны к работе сразу.

      • mkovalevskyi
        /#23045678

        Только не китайского. А китайского за 100 рублей набор.

        И есть на эту тему чудный не факт что анекдот из далеких 90-х:
        — вот чертежи, сколько будет стоить?
        — 10 центов штука
        — а что б количество кнопок совпадало с ожидаемым?
        — 50 центов
        — а что б не было страшно в руки брать?
        — 1 доллар
        — а что б не ломалось?
        — ну тогда десятка…

        • sshikov
          /#23045718

          Ну кстати, оно не 100 рублей стоило. Хотя да, набор конечно дешевейший был. Тут скорее вопрос в том, что и за одну и туже цену можно нарваться как на что-то приличное, так и на полный отстой.

          • mkovalevskyi
            /#23046204

            Это до вас оно дошло не за 100. А я условную цену с завода имел ввиду.
            А про совесть маркетологов, которые ту цену чуток подтюнили, я писать не буду, не обладаю достаточным запасом соответствующих терминов )

  3. Mishootk
    /#23043406

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


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


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

  4. Mnemonik
    /#23043564 / +2

    Блин, я читал и прям ждал что в конце будет реклама «хочешь стать программистом? трёхнедельный курс с гарантией трудоустройства…»

    Прям немножко расстроился. Без такой вишенки статья выглядит хорошей, но неполной =(

  5. sbnur
    /#23043868

    В мире много чего отстойного — однако он существует

  6. adictive_max
    /#23043920

    Почему-то никто из нытиков в упор не желает замечать 3-й «проблемы» — отрасль очень быстро развивается. Невозможно «в совершенстве освоить все навыки», если они появляются быстрее, чем их массово успевают осваивать. То самое «нужен lead-senior c 5-ю годами опыта по технологии, вышедшей в позапрошлом году».
    А так есть куча спецов, которые с 90-х в совершенстве осваивают инструменты из 90-х. Только вы же сами их и не возьмёте на работу, потому что вам не нужен софт, написанный как будто в 90-е.

    • kirillbdev
      /#23044278

      Что мешает использовать стабильные проверенные технологии? И я не говорю о чем-то древнем. Куча продуктов так и работают. Пусть отрасль хоть 7-ми мильными шагами развивается. Все обычно крутиться вокруг фундаментальных основ.

      Проблема в спецах, которые при выходе каждой новой технологии тут же стремятся её освоить, забрасывая все предыдущие, считая их «древними» (привет js'еры). А еще проблема в том же найме, когда не почитав даты выхода релиза новой технологии, тут же ищут синьёра с 5+ лет по ней.

      • Revertis
        /#23045472

        Ну вот можно было бы разработать нормальную прогу под Windows, всё равно ведь на 95% компов в РФ стоит Винда. Но какой-нибудь менеджер потребует, чтобы запускалось и на его макинтоше. Поэтому приходится из говна и палок используя новые технологии делать какую-то кроссплатформщину, которая нужна маргиналам, чаще всего не входящих в целевую аудиторию.

      • namee
        /#23047232

        Технологии сейчас устаревают до того, как становятся стабильными и проверенными. На примере Unity3D. Мне очень нравится стабильный, быстрый и надёжный юнити версии 5.6. Но на нём под ось и под дроид не получится выпустить приложение. Потому как новшества, обязательные для дроида и оси были внедрены в свежий, полный багов и фич юнити в прошлом году. А без этих обязательных новшеств в стор не пройти.

      • t-nick
        /#23047602

        Новые платформы: железо, ОС, браузеры. Любое ПО требует обновлений для работы на новой/обновленной платформе. Может получиться и в итоге получается так, что дописать поддержку (в компиляторе, интерпретаторе, виртуальной машине и т.п.) нового железа будет дорого или некому. К тому же возникают проблемы с обратной совместимостью. Сложность такой системы растет, как и количество багов. В итоге выгоднее взять новый стек технологий, без легаси, и написать новый продукт на нём. Существующие продукты так же зачастую переписываются, так как иначе не будут удовлетворять потребностям рынка.
        Потом, новые технологии появляются не на пустом месте, они призваны решить проблемы существующие в старых технологиях (скорость разработки, мультиплатформенность, масштабируемость и т.п.).

  7. DYUMON
    /#23046216

    Что поделать, чем больше программистов, тем меньше программистов.

  8. Tamahome
    /#23046374 / +1

    Качественно, дёшево, быстро.
    Заказчика интересует только последние 2, к этому добавляются неправильные KPI и общий беспорядок-бюрократия.

    Вокруг куча стёмных товаров, это так во всех сферах, состав продуктов уже страшно даже читать...

    Но в сфере ПО есть и интересные моменты, когда разработчик откровенный баг или отсутствие базового функционала выдает за фичу, и предлагает заплатить за доработку.. (биллинги конечно это особый мир вымогательства)

    • mkovalevskyi
      /#23054080

      Так не только в ПО. Поваренная соль без ГМО, растительное масло без холестерина, недели высокой моды в неважногде, айфоны без зарядок, боинги с чуток улучшенным мотором, моторы с пониженым выбросом СО2… Это имеет место быть во всех сферах, было б желание увидеть )

  9. tangro
    /#23047404

    А ещё беда в том, что где-то на границе Competent и Master открывается дополнительная сюжетная ветка «пойти в менеджеры» и многие люди выбирают её. В результате из тех, кто спустя пару лет мог бы стать хорошим программистом, получается ещё один средненький менеджер.

    • mkovalevskyi
      /#23049938

      собственно, так умерла нокия в свое время.