Почему мы пишем программы такого низкого качества?

Автор оригинала: Jake Voytko
  • Перевод

Проектировщики самолёта отвечают на вопрос о его безопасности:
— Ничто не вечно, но современные авиалайнеры невероятно устойчивы, а самолёт — самый безопасный транспорт в мире.
Инженеры-строители отвечают о безопасности лифтов:
— Лифты защищены множеством отказоустойчивых механизмов. Их практически невозможно уронить в свободное падение.
Программисты отвечают на вопрос об электронном голосовании:
— Это просто ужасно.
— Серьёзно?
— Абсолютно. Не доверяйте программам для электронного голосования и не верьте никому, кто уверяет в их надёжности.
— Почему?
— Не совсем знаю, как это выразить, но вся наша область плоха в том, что мы делаем, и если вы будете полагаться на нас, то все умрут.
— Говорят, что надёжность гарантируется технологией под названием «блокчейн».
— А-а-а-а-а!!! Что бы они ни говорили, не прикасайтесь к этому! Закопайте поглубже. Не забудьте перчатки!

Источник: XKCD, лицензия Creative Commons 2.5

Глюк мобильного приложения для подсчёта голосов на прошлой неделе добавил хаоса на Съезде фракций Демократической партии в Айове. Через несколько часов после открытия собраний по всему штату стало ясно: что-то пошло не так. Результаты неизвестны до сих пор. Появились сообщения с описанием технических проблем и недоразумений. Демократическая партия Айовы опубликовала заявление, в котором отрицает слухи о кибератаке, но подтверждает технические проблемы с мобильным приложением.

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

По твиттеру пошла волна хэштегов #app и #problems, а инженеры-программисты ссылались на КДПВ. Я тоже так думал. Слова с этой карикатуры хорошо резюмируют общее ощущение происходящего: «Не совсем знаю, как это выразить, но вся наша область плоха в том, что мы делаем, и если вы будете полагаться на нас, то все умрут». Инженеры-программисты не говорят это прямо. Но звучит очень похоже. Что мы имеем в виду?

Вот что мы имеем в виду: мы хорошо делаем программное обеспечение при условии, что последствия неудачи не имеют значения. В среднем программы достаточно хороши, чтобы как-то работать. Тем не менее, мы не особо удивляемся ошибкам в большинстве программ. Это не какие-то редкие инциденты. Многие распространённые практики в программной инженерии исходят из предположения, что сбои являются нормой, а главное — новые функции. Неудача действительно стоит дёшево. Если онлайн-сервис от одной из крупнейших компаний полностью отключится на два часа, об этом забудут уже через неделю. Это предположение воплощается в распространённых мантрах: «Двигайся быстро и всё ломай» (Move fast and break things), «Выкатывай и повторяй цикл» (launch and iterate).

Рынок щедро вознаграждает за такое «безответственное» поведение. Во многих веб-компаниях небольшая прибыль с одного пользователя умножается на миллионы (или миллиарды!) пользователей. Это выгодно для компаний с потребительскими приложениями или веб-сайтами. Реализация дорогостоящая, но стоимость конечна, а распространение почти бесплатное. Индустрия потребительского ПО нашла компромисс: мы снижаем скорость внедрения ровно настолько, чтобы поддерживать наш уровень дефектов умеренно низким, но не слишком.

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

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

Как работает программирование в веб-компаниях?


Представим гипотетическую компанию QwertyCo. Это ориентированная на потребителя софтверная компания, которая зарабатывает 100 миллионов долларов в год. Мы можем оценить размер QwertyCo, сравнивая с другими компаниями. WP Engine, WordPress-хостинг, достиг $100 млн ARR в 2018 году. Blue Apron выручил за год $667 млн. Таким образом, QwertyCo — это компания среднего размера. У неё от нескольких десятков до нескольких сотен инженеров и она не выпускала акции в публичное обращение.

Во-первых, рассмотрим экономику управления проектами в QwertyCo. Руководители узнали, что вы не хотите мгновенно объявить о появлении новой функции. У вас компромисс между качеством программного обеспечения, дедлайном и скоростью реализации.

Насколько важно для них качество программного обеспечения? Не особо. Если веб-сайт QwertyCo не работает в течение 24 часов в год, они оценивают потерю всего в $273 972 (предполагая, что время безотказной работы линейно коррелирует с доходом). Говорят, что сайт часто отключается на 15 минут, и никого это особо не волнует. Если функция выведет сайт из строя, они откатят её обратно и повторят попытку позже. Повторные попытки дёшево стоят.

Насколько ценна новая функция для QwertyCo? Основываясь на моих личных наблюдениях, один месяц работы одного инженера способен изменить доход оптимизированного сайта в пределах от −2% до 1%. Это ежемесячный шанс получить 1 миллион долларов дополнительного дохода QwertyCo для каждого инженера. Такие методы, как A/B-тестирование, даже смягчают ошибки: в течение нескольких недель вы можете обнаружить негативные или нейтральные изменения и удалить эти функции. Плохие характеристики стоят дёшево — они активны конечное количество времени. Выигрыш же получается навсегда. Даже невысокий процент выигрышных ставок приносит прибыль QwertyCo.

С учётом плюсов и минусов, когда QwertyCo должна выпустить функцию? Экономический расчёт показывает, что даже высокорискованные функции следует запускать, если они иногда приносят прибыль. Соответственно, каждый проект превращается в оптимизационную игру: «Сколько можно реализовать к этой дате?», «Сколько времени требуется для реализации всего проекта? Что, если убрать из него X? Что, если убрать X и Y? Как ускорить реализацию определённой части?»

Теперь рассмотрим программный проект с точки зрения инженера-программиста.

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

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

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

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

Таким образом, у менеджмента и разработки противоположные точки зрения на качество. Руководство согласно на высокую частоту ошибок (но не слишком высокую), а инженеры хотят, чтобы ошибок был абсолютный минимум.

Как это влияет на управление проектами? Менеджеры и разработчики разделяют проект на небольшие задачи. Время выполнения проекта зависит от количества задач и количества инженеров. Чаще всего проект занимает слишком много времени — и его корректируют путём удаления функций. Затем инженеры выполняют поставленные задачи. Реализация задачи часто выполняется внутри «спринта». Если время спринта составляет две недели, то у каждой задачи неявный двухнедельный таймер. Однако задания часто занимают больше времени, чем вы думаете. Инженеры принимают жёсткие решения о приоритизации, чтобы закончить вовремя: «Я могу сделать это к концу спринта, если напишу базовые тесты и если я пропущу этот рефакторинг, который планировал». Спринты оказывают постоянное давление, подгоняя разработчика. Это означает, что инженер может либо пойти на компромисс по качеству, либо признать неудачу на следующей планёрке.

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

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

Что произойдёт, если нарушены допущения такой экономической модели?


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

Краткое примечание: в этом разделе я употребляю фразу «высокорискованные» как сокращение для «ситуаций с невозможностью повторной попытки» и «ситуаций с дорогостоящей возможностью повторной попытки».

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

Во-первых, инженерная логистика: вы должны написать как приложение для Android, так и приложение для iPhone. Отчётность является центральным требованием, поэтому необходим сервер. Запутанные правила собрания должны быть закодированы как в клиенте, так и на сервере. Система должна сообщать о результатах конечному пользователю; это ещё один интерфейс, который необходимо запрограммировать. Демократическая партия, вероятно, имеет требования к проверке и отчётности, которые вы должны записать в приложение. К тому же, будет весьма некстати, если во время собрания выйдет из строя сервер, поэтому нужно внедрить какую-то систему мониторинга.

Далее, как проверять приложение? Один из вариантов — тестирование у пользователей. Вы показываете картинки гипотетического приложения потенциальным пользователям — и задаёте вопросы типа «Как вы думаете, что делает этот экран?» и «Если вы хотите добраться до $a_thing, куда вы нажмёте?» Дизайн всегда требует нескольких итераций, поэтому высокого качества разумно ожидать после нескольких раундов такого тестирования. Крупные компании часто проводят несколько раундов перед внедрением важных функций. Иногда даже отменяют функции после получения обратной связи, прежде чем написать хоть строчку кода. Пользовательское тестирование обходится дёшево. Разве трудно найти пять человек, которые уделят анкете 15 минут, получив в подарок подарочную карту за пять долларов? В нашем деле самое сложное — составить репрезентативную выборку, которая соответствует демократическим представителям штата Айова.

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

Далее, в интернете полно негодяев. Например, российские группы широко распространяли дезинформацию через социальные медиа, такие как Facebook, Reddit и Twitter. Поэтому нужно убедиться, что не вмешается никто посторонний. Как проверить аутентичность результатов? Кроме негодяев, в интернете полно шутников, которые готовы сорвать любое мероприятие просто по приколу. Насколько наша система противостоит DDoS-атакам? Если нет, то есть ли запасной план? Кто несёт ответственность за введение запасного плана, сообщив об этом на собраниях? Что произойдёт, если учётные записи участников взломают? Если в компании нет экспертов по безопасности, вполне вероятно, что приложение должно пройти независимый аудит.

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

Ладно, прекратим перечислять проблемы. Понятно одно: требуется куча времени и ресурсов, чтобы убедиться, что всё работает.

Создателям приложения Iowa Caucus дали $60 000 и два месяца. У них было четыре программиста. Этой суммы недостаточно для зарплаты четырёх хороших программистов и остальных расходов. Деньги нельзя обменять на время. Помощи извне практически нет.

Представим, что вы применяете общепринятую практику удаления задач из проекта до тех пор, пока сроки не станут реально выполнимы. Вы сделаете всё возможное, чтобы сэкономить время. Предварительный обзор для каталога приложений часто занимает меньше дня, но в худшем случае может растянуться на неделю, а приложение могут отклонить. Так что давайте пропустим это: члены Демократической партии будут загружать приложение через ссылки для бета-тестирования. Даже с бесплатной проверкой безопасности потребуется слишком много времени, чтобы выполнить все их рекомендации. Поэтому отказываемся от проверки безопасности. Возможно, во время разработки бэкенда вы заплатили дизайнеру $1000 за создание макета приложения и логотипа. Вы планируете один раунд пользовательского тестирования (но затем пропустите его, когда сроки выйдут). Выкатывай быстро и повторяй цикл! Всё всегда можно исправить.

А программирование всегда занимает больше времени, чем ожидалось! Вы столкнётесь с затыками. Во-первых, правила проведения собраний не совсем ясные. Это всегда выясняется, когда цифровое решение накладывают на аналоговый мир. Реальный мир может смириться с неоднозначностью и непоследовательностью, а цифровой мир — нет. В ответ на ваши вопросы комитет Демократической партии подготовит разъяснения. Это задержит вас. Комитет также может изменить правила в последнюю секунду. Это приведёт к тому, что вы измените приложение перед самым дедлайном. Далее, у вас несколько разработчиков, что означает оверхед на координацию. Каждый ли кодер на 100% разбирается и в мобильной, и в серверной разработке? Все ли они в совершенстве владеют React Native? JS? Typescript? Клиент-серверными коммуникациями? Какие именно фреймворки и библиотеки вы выбрали? Каждое «Нет» добавляет времени на разработку, чтобы учесть координацию и обучение. Все ли довольны тестовыми фреймворками, которые вы используете? Просто шучу. Какие там тесты… Да, сначала написали пару тестов, но приложение так быстро изменилось, что их удалили.

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

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

Но аврал отразился на демократическом собрании Айовы. По ходу проведения мероприятий начали поступать звонки с жалобами на приложение. Начали приходить теоретически невозможные результаты или дубликаты. Вскоре весёлые программисты радостно публикуют картинки с КДПВ и заявляют, что Съезду фракций в Айове вообще не следовало заказывать приложение, а голосование можно доверить только бумажным технологиям.

Выводы


Это эссе помогло лично мне сделать вывод: при планировании проекта нужно формализовать стоимость переделки. Я интуитивно делал это в прошлом, но её следует внятно конкретизировать. Такая формализация помогает понять, какие задачи нельзя провалить ни в коем случае. Это как было у меня в мобильной робототехнике: там длинные циклы внедрения, а ущерб от сбоя мог зашкаливать. Мы тратили много времени на разработку мониторинга и создание надёжных способов подавления и остановки вышедших из-под контроля систем. Я также в течение десяти лет работал с потребительскими веб-сервисами, где последствия неудачи ниже. Здесь выше готовность брать краткосрочные долги и продвигаться вперёд с риском временного сбоя, особенно когда откат обходится дёшево, а потеря данных маловероятна. По крайней мере, стимулы подталкивают именно к такому поведению. В нашей отрасли есть специальные методики для предотвращения подобных проблем. Одна из них — расследование воображаемых сбоев (pre-mortem). Нужно почаще этим заниматься.

У айовского провала есть и положительный результат. Некоторые не имеющие отношения к IT поняли, что в программах бывают ошибки. В ближайшие годы спонсоры разработки приложений для политических партий начнут спрашивать: «Какие гарантии, что не повторится ситуация со Съездом фракций в Айове?» Возможно, они познакомятся с литературой, которая пытается научить менеджеров, как правильно работать с инженерами. Например, у Министерства обороны США есть руководство под названием «Как распознать липовые проекты Agile», которое описывает подозрительные признаки при заключении контракта. На форумах для стартаперов полно нетехнарей, которые просят (и получают) советы по найму разработчиков.

IT-индустрия ничему не научилась. Съезд фракций в Айове дал шанс изучить, как предположение о «высокой стоимости ошибки» изменит наши основные процессы. Но мы не воспользовались этой возможностью и ничего из неё не извлекли. Индустрия потребительского ПО не обращает внимания на риски ошибок. Фактически, мы даже радуемся ошибкам. Если внешний мир заинтересован в повышении качества нашего кода в определённых областях, то они должны регулировать эти области. Это будет не первый случай. Закон Сарбейнза — Оксли и HIPAA — вот примеры регулирования в сфере разработки с экономической моделью веб-сайта. Регулирования недостаточно, но может оказаться, что оно необходимо.

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

Подробнее
Реклама

Комментарии 92

    –1
    такъ победим
      +8

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

        0
        Как раз при добавлении фич и всего остального, во втором прочтении кода, все и правиться. В лучшем случае, иначе костыли.
        +9

        Просто айтишники достигают предела некомпетентности
        А в других сферах с этим куда хуже


        Например терапевты в поликлинике убивают больше пациентов чем хирурги

          +1
          Например терапевты в поликлинике убивают больше пациентов чем хирурги

          Мне кажется это спорное утверждение. А терапевтов и хирургов одинаковое количество? И какой поток пациентов проходит через первых и вторых?
            +10
            Терапевт всё знает, но ничего не может. Хирург всё может, но ничего не знает. И только патологоанатом всё знает и всё может, но уже поздно.
            +5

            Идиотский комикс. При всём уважении к xkcd.


            Цитата из кода боинга:


            if (angle < 270.0) quadrant = 3;
            else if (angle > 270.0) quadrant = 4;

            https://catless.ncl.ac.uk/Risks/31/57#subj22


            Причина почему у Боингов проблема при посадке на некоторые полосы.


            Так что, не надо доверять софту.

              +4

              Не софту, а автору такого софта. Мой софт и плавает, и летает. Правда о проблеме 2038 года тогда НИКТО не думал. Я даже во сне не мог предположить, что мое ПО до него доживет.

                0

                Я отчётливо помню, что на волне обсуждения "проблемы 2k" упоминалась в том числе и "проблема 2k38"

                  +1
                  А можете уточнить, на чём же именно не стоит летать и плавать в 2038 году? )
                    +4

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

                      +1

                      Т.е. на велосипеде с надувным матрасом и в каске...

                        0

                        Нет, просто подальше от мест, где малые синхронные отказы систем могут привести к лавинному эффекту.

                        0
                        Авось, за 18 лет успеют исправить
                      0
                      Я даже во сне не мог предположить, что мое ПО до него доживет.
                      Мне приходилось писать тесты для бизнес-логики с incomingParam < DateTime.Now. Входящий параметр я установил в 2049-01-01. Соответственно, через 30 лет тесты сломаются.

                      Кто знает, может, спустя все эти годы, некий программист увидит упавший билд, прочитает мой комментарий к тем тестам, и поставит мне, старику, бутылочку холодного сока.
                      +4
                      Цитата из кода боинга:

                      Это не цитата из кода боинга, это лишь предположение одного человека о том что оно так устроено. Но да, проблема вида «все экраны отключаются при заходе на посадку с курсом 270 в таких-то аэропортах» весьма похожа
                      +3
                      Главная проблема все-таки в том, что есть программирование и есть разработка программного обеспечения. Запрограммировать может быть и за день можно, а вот вся эта возня с тестированием и развертыванием — это не интересная рутина. По работе приходится часто заказывать разработку на аутсорс, постоянно присылают оценку без учета тестирования и развертывания. А когда про них спрашиваю напрямую, то включают в ценник, но в виде одной строчки: Тестирование и развертывание +2 недели +100500 денег :)
                        +14

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


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

                          +3
                          а то иначе не дай боже кто-то где-то сделает быстрее нас и всё

                          Кстати, это убеждение совершенно идиотское. «Кто первый встал — того и тапки» работает лишь в отдельных сегментах, притом с длиннющим списком условий. Чаще всего происходит наоборот — успеха добивается тот, кто позволил торопыгам первыми выкатить на рынок сырой продукт, а потом выкатил свой законченный.
                            +2
                            Ваши слова да в уши всем руководителям :)
                              +3

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


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


                              Еще хуже, если и умных на старт не нашлось. Все слышали про юниттесты и тестирование, но что это за зверь… каждому рисует его воображение разную картинку. От розового единорога, до кошмарного коня апокалипса. Там вообще хз что выходит из под пресса. Юнит тесты гоняют на общей базе данных, оптимизируют код на миллисекунды, а запросы к базе отрабатывают по 5 минут.


                              Короче про это все писали уже с 70-х годов, просто никто книжки не читает ))

                                0
                                В приведённом примере софт для голосования, это не открытый рынок, где все конкурируют, а скорее всего выбрали либо на конкурсной основе или на поле для игры в гольф подрядчика.
                                С учётом, что где-то прочитал о том, что софт писала контора, связанная с объявленным победителем, то вопрос о методе выбора действительно инетересен
                                  0
                                  Вроде как они там все повязаны были Acronym, Shadow Inc. Короче даже конкурса никакого не было. Обычная история. Нашел еще

                                  A precinct captain for Sanders, who requested anonymity because they were not authorized to talk to the press, confirmed that the rollout was rushed. “We didn’t know about the app until like a month ago. And we didn’t have access to the app until like three days ago,” the source said.

                                  “This app has never been used in any real election or tested at a statewide scale and it’s only been contemplated for use for two months now,” David Jefferson, who also serves on the board of Verified Voting, a nonpartisan election integrity organization, told the New York Times.


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

                              Только есть нюанс — то что люди хотят/просят/заказывают на самом деле не всегда является тем, что действительно нужно )
                                0
                                Нужно кому?
                                Приведите пожалуйста пример того, что заказывают люди и почему оно не нужно (кому?). А то без примера ваша мысль непонятна.
                                  0
                                  Нужно кому?

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

                                  Приведите пожалуйста пример того, что заказывают люди и почему оно не нужно (кому?)

                                  Не нужно людям для достижения их целей.
                                  Детям не нужны четырехколесные велосипеды чтобы научиться кататься на взрослых, потому что проблема не педали крутить, а равновесие держать. И чтобы научиться держать равновесие лучше подходят двухколёсные велобеги.
                                  Пример честно подслушан в интернете, и вроде как изначально приведён был Аланом Кеем в одном из его докладов, но я пока не выяснил в каком.
                                  На самом деле, если задуматься, в жизни много таких ситуаций.
                                    0
                                    ОКей, но я так и не понимаю причем здесь высокое/низкое качество решения и быстро/медленно разработать?

                                    Ваш вопрос имеет место быть, но он никак не влияет на то как (быстро/некачественно или наоборот) мы будет решать проблему клиента. Мы можем посоветовать клиенту лучшее решение, если оно есть в его вопросе, но всё равно нам придется дальше делать выбор как это решение сделать.

                                    Здесь вопрос больше про то, что бизнесу по большому счету вообще наплевать на качество наших приложений (я не беру в расчет космическую и медицинскую отрасль, где ошибка в программе стоит жизней). Просто больно смотреть как ребята, хорошие разработчики, дизайнеры и прочие хотят делать хорошо, а им за это дают по рукам.
                                      0
                                      ОКей, но я так и не понимаю причем здесь высокое/низкое качество решения и быстро/медленно разработать?

                                      Ваш вопрос имеет место быть, но он никак не влияет на то как (быстро/некачественно или наоборот) мы будет решать проблему клиента. Мы можем посоветовать клиенту лучшее решение, если оно есть в его вопросе, но всё равно нам придется дальше делать выбор как это решение сделать.

                                      Так в том и дело, что из того что бизнес просит делать быстро(или даже некачественно), на самом деле не обязательно следует то, что ему хорошее качество не нужно.

                                      Про быстро/качественно тоже есть нюанс, писал ниже — habr.com/en/post/488194/#comment_21275686

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

                                      Предлагаю голосовать ногами :)
                                      Ну и нужен диалог, конечно, по возможности.
                                    +1
                                    У вас никогда не было такой ситуации когда к вам приходит заказчик и говорит что-то вроде «мне нужна вебстраничка». А когда спрашиваешь зачем ему нужна вебстраничка, то он говорит «ну чтобы мне могли люди электронные письма писать».

                                    Ну и шутка про "семь красных невидимых перпендикулярных линий" тоже не на пустом месте появилась.
                                  +1

                                  Платят за time to market — стараются делать быстро, платят за безопасность — стараются делать безопасно, всё разумно. И инструменты, и методологии, и стандарты есть под оба случая.


                                  Другая беда с программными продуктами — с помощью технических средств пытаются решить чисто организационные. Я долго пытался понять, почему внедрение CRM/ERP и 1С — это почему-то IT, хотя вполне себе есть администраторы, документоведы, учётчики, кадровики, экономисты и бухгалтеры. Единственный ответ, который я смог найти, в том, что от специалистов этих специальностей никто не ждёт чуда (и даже высокой квалификации), а от айтишников до сих пор ждут, что те сделают всем внезапное хорошо, и пока что готовы айтишникам платить высокую зарплату, вместо того, чтобы более тщательно подбирать и контролировать традиционных специалистов, ну и платить уже им за работу.

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

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

                                  А я вам скажу откуда — пока программы пишут люди, программы будут давать сбои. Человеку свойственно ошибаться. А компьютеры не смогут писать программы, потому что для этого человек должен будет им обьяснить, что писать. И мы опять вернулись к изначальной проблеме — человек несовершенен, и ему свойственно ошибаться. У попа была собака…
                                    0

                                    Так и сейчас большая часть ошибок, вернее того, что воспринимается как ошибка, появляется из-за неполных и(или) противоречивых требований.

                                    0
                                    Вроде бы цифры в статье убеждают меня в том, что софт с большим количеством фич зарабатывает больше чем софт с меньшим количеством, даже не смотря на баги. Но когда мне надоело мириться с очередным багом Lastpass, Я перенёс свои данные в 1Password и был несказанно рад. Пусть в 1Password нельзя создать вложение к записи, нет простого шаринга с другими пользователями и генератор паролей не такой продвинутый. Зато работает стабильно во всех браузерах, на десктопе, телефоне и iPad.
                                    Мне кажется, на конкурентном рынке отсутствие багов может перевесить обилие фич.
                                      +6
                                      Что произойдёт, если нарушены допущения такой экономической модели не работают?

                                      Переводчики работают не лучше программистов, вычитывать хотя бы заголовки им некогда…
                                        +2
                                        Почему, почему…

                                        Потому что договорились не считать обманом потребителя продукт, в котором заранее заложено низкое качество.
                                        Все эти AGILE/SCRUM — это коллективный договор о вранье.
                                        Бизнесу врут, что его слушают и что он самый ценный в этом договоре, исполнителям врут, что они ценный ресурс. А на деле бизнес получает вечную разработку вместо конечного продукта. Программисты — жизнь с чувством вины, что костыли пустили в прод (но многое эти м довольны, кстати). А манагеры — простор для манипуляций и теми и другими.
                                        Экономинка вранья и двойных стандартов.
                                          +2
                                          Потому что договорились не считать обманом потребителя продукт, в котором заранее заложено низкое качество.
                                          Все эти AGILE/SCRUM — это коллективный договор о вранье.
                                          Бизнесу врут, что его слушают и что он самый ценный в этом договоре, исполнителям врут, что они ценный ресурс.

                                          А я думаю проблема не в договоре а в его понимании, и в том под какими предлогами людям его продают. Причём продают не авторы договора(вспомнилось Agile is dead от одного из авторов манифеста).

                                          Agile стал модным, его стали «покупать» под предлогом того что разработчики будут доставлять больше фич за то же время, только не вникали за счёт чего.

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

                                          Вкратце, я думаю это извечная проблема того в сознаниях людей становятся плохими подходы после увиденных некорректных их реализаций и применений — ну не виноват микроскоп, что им гвози забивают.
                                            +2
                                            Все эти AGILE/SCRUM — это коллективный договор о вранье.

                                            С таким же основанием можно заявлять что «все эти UnitTests это коллективный договор о вранье» или «все эти ООЯП это коллективный договор о вранье».
                                            Это всё инструменты и их можно использовать правильно или неправильно. Но только от того, что кто-то не умеет правильно пользоваться инструментом, сам этот инструмент плохим не становится.

                                            P.S. А если взять конкретно AGILE/SCRUM, то сейчас этими словами называют всё что угодно. И даже вещи которые к AGILE/SCRUM вообще никакого отношения не имеют.
                                              +1

                                              Постоянно слышу о том, что это не Agile/Scrum плохо, а вы его готовить не умеете. Забавно то, что никогда никто не говорит, как его правильно готовить, когда вообще начинать готовку и каковы критерии "нормальности". Просто все виды agile какие удалось повидать — были именно тем, чем написано — коллективным договором о вранье)


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


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

                                                +2
                                                Забавно то, что никогда никто не говорит, как его правильно готовить, когда вообще начинать готовку и каковы критерии «нормальности».

                                                Ну если ваш «аджайл» хоть где-то «кастомизирован» настолько что противоречит манифесту, то с вероятностью 99% он у вас уже ненормальный.

                                                А давать вам рецепты по скраму на хабре это примерно как ставить диагноз по фотографии — ничего хорошего из этого скорее всего не выйдет. Вам нужен человек, который придёт к вам, посмотрит на ваши задачи и процессы и только тогда начнёт давать советы. И возможно что первое что он скажет это будет «для вас аджайл/скрам вообще не вариант». И в этом как бы тоже нет ничего ужасного.
                                                  +2
                                                  В итоге всё почему-то раз за разом описывается словами: если у вас это работает, то это правильный аджаил, а если нет — то полюбому не правильный…
                                                    +1
                                                    Ну может быть так описывается потому что оно так и есть? :)
                                                      +1
                                                      Тут должен был быть комментарий про Чайник Рассела и о том, кто должен доказывать существование бога, но… мне сегодня уже надоело с вами общаться с отсылкой к фактам, когда с вашего будет «мне так кажется и я верю»
                                                        0

                                                        Чем моё "мне так кажется" принципиально отличается от вашего "мне так кажется"?

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

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


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

                                                  +2
                                                  В одной команде все прижилось и все у них было хорошо. И фидбек, и качество, и скорость, а в другой больше споров, четрехкратные задержки по срокам, нулевое качество софта и т.д. и т.п.

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

                                                    +3
                                                    самоорганизованная команда мотивированных профессионалов
                                                    Которая и без всякого аджайла вероятно сможет добиться результатов? )
                                                      +2

                                                      Так нахрена самоорганизованной команде профессионалов какая-то хрень сбоку, с названием аджайл?) Да и в целом какая-то система организации работы? Ведь они сами себе самоорганизованы.

                                                        +3
                                                        Ну потому что какая-то организация им всё равно нужна. И какие-то процессы им всё равно нужны.

                                                        Так зачем выдумывать абсолютно всё с нуля если можно взять что-то уже имеющееся? И мало того что имеющееся, но к тому же уже с готовыми инструментами и/или интеграцией в распространённые инструменты.
                                                          +2

                                                          Ну, из вышесказанного получается, что аджайл:


                                                          1) Невозможен нигде, кроме как в среде крутых сработавшихся специалистоа. Среди "индусов" (обычных линейных программистов) его не организуешь.


                                                          2) Практически бесполезен, т.к. буквально невоспроизводим. То, что в какой-то команде собрались близкие по духу компетентные люди — это дело случая, поэтому "внедрять аджайл" на предприятии — дело заведомо гиблое.


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


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


                                                          У них нет цели стать начальником, им просто нравится пилить код, и шутить шутейки на кухне ') У них нет доли в компании, нет каких-то иных стимулов рвать жопу ради работы) У них вот семья, дочь во второй класс пошла, ипотека скоро закончится, ремонт вот в копейку влетает, родители уже что-то часто начали болеть. Им до всей этой беготни и амбиций просто нет дела :)


                                                          Так зачем, скажите мне, такому человеку аджайл?)

                                                            +2
                                                            Ну во первых именно «аджайл» это всего лишь набор принципов и следовать им можно хоть в одиночку. Было бы желание.

                                                            И это как бы совсем не про «рвать жопу ради работы» и какие-то амбиции, а скорее о том как писать нормальный и нужный код и чтобы тебе при этом не мешали какие-то левые люди. Как минимум так для меня лично выглядит «короткое содержание» аджайл.

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

                                                              Весь аджайл построен на том, что тебе мешают какие-то левые люди. Мне мешают стенд-апы, мешают постоянно меняющиеся требования, мешает то, что надо "быстрее", а не "качественнее".


                                                              Мне, как человеку, который хочет просто решать задачу, водопад подходит больше всего :) Согласовали, зафиксировали, пилим потихоньку по плану :) Весь этот аджайл, мне, как рядовому сотруднику — НЕ НУЖЕН. Он нужен бизнесу, ведь ему приходится жить в вечном эпилептическом припадке смены требований :)


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

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


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

                                                              Мне кажется я не до конца понял вашу мысль. Что именно должен сделать/сказать менеджер, что я должен подумать, что он учит меня делать мою работу :) Ну, т.е. типа не будет же он тыкать пальцем в монитор и говорить: "вот тут переменную обнули!"
                                                              Наверное я очень везучий человек, но никогда не работал с такими менеджерами. Обычно PM ранее программировал, а если нет, просто доверял своей команде.

                                                                +2
                                                                Весь аджайл построен на том, что тебе мешают какие-то левые люди. Мне мешают стенд-апы, мешают постоянно меняющиеся требования, мешает то, что надо «быстрее», а не «качественнее».

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

                                                                Согласовали, зафиксировали, пилим потихоньку по плану :)

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

                                                                Мне кажется я не до конца понял вашу мысль. Что именно должен сделать/сказать менеджер, что я должен подумать, что он учит меня делать мою работу :) Ну, т.е. типа не будет же он тыкать пальцем в монитор и говорить: «вот тут переменную обнули!»

                                                                Ну я скорее о вещах вроде «на рефакторинг времени нет», «запилите быстро костыль, потом когда-нибудь переделаем», «юнит тесты не нужны» или наоборот «нам нужно 100% покрытия юнит тестами».

                                                                С аджайлом видимо не знаком совсем, судя по тому, что у меня какое-то тотальное непонимание чего мне тут целую ветку пытаются донести.

                                                                По тому что вы пишите похоже так оно и есть. То, что вы пишите, это скорее какой-то «аджайл курильщика». Так бы я лично тоже работать не хотел.
                                                                  0
                                                                  Весь аджайл построен на том, что тебе мешают какие-то левые люди. Мне мешают стенд-апы, мешают постоянно меняющиеся требования, мешает то, что надо "быстрее", а не "качественнее".

                                                                  Аджайл бывает разным, но вы похоже больше о Скраме. Так вот, в Скраме левые люди мешать не должны, есть скрам-команда и всё. С "левыми людьми" взаимодействие команды регламентировано обычно и идёт раз в спринт (по дефолту две недели). Если члены вашей команды для вас левые люди, то команды у вас нет, а значит обязательное условие скрама не выполняется.

                                                            0

                                                            С самоорганизованной командой надо как-то взаимодействовать бизнесу. Аджайл — это типа архитектуры этого взаимодействия как REST, а скрам — типа протокола взаимодействия по этой архитектуре, типа HTTP

                                                    +3
                                                    А может, просто не нужно нанимать всяких дерьмокодеров за пять копеек для создания критически важных систем, да ещё стегать их кнутом, вынуждая делать пятилетнюю работу за полгода? Есть же примеры высоконадёжных систем, в т.ч. и математически верифицированных.
                                                      +3
                                                      Результат от «всяких дерьмокодеров за пять копеек для создания критически важных систем, да ещё стегать их кнутом, вынуждая делать пятилетнюю работу за полгода» будет точно таким же как и от высокооплачиваемых специалистов.
                                                      Так зачем переплачивать?
                                                      0

                                                      Да, согласен

                                                        +5
                                                        Два раза прочитал, подумал, и все же напишу свой коммент.
                                                        А почему вы решили что весь софт низкого качества? Я пишу софт для встроенных систем. Ошибка в моем коже может «бабахнуть» очень хорошо, поэтому софт из моей конторы выходит качественный. Перепровенный ревью, пятью разновидностями тестов. При этом написать 100 строк кода в день — это даже много. При этом работа по Аджайлу. И это работает.
                                                        Результат — много лет на рынке и хорошая репутация.
                                                        Вывод — там где надо с кодом все в порядке, где неважно, там всякое может быть.
                                                          0
                                                          Вывод — там где надо с кодом все в порядке

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

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

                                                              0
                                                              И что следует из всего вами перечисленного?
                                                              Как репутационные риски остановили Боинг от найма дешевых индусов для разработки софта?
                                                              И что толку от этих репутаций каких-то людей из Боинга, сотням погибших пассажиров и их семей?
                                                              Где тут вообще логическая связка обычными приложениями и EULA, если речь идет про «там где надо с кодом все в порядке»? Или в самолетах качество «не надо»?
                                                                +2
                                                                Ну всё-таки после всех этих скандалов у Боинга заметные проблемы и куча отказов от заказов. И наверняка куча заказов была из-за этого не сделана. И им в общем-то придётся на всё это как-то реагировать или рано или поздно фирма разорится.

                                                                С другой стороны баги какого-нибудь фейсбука мало кого интересуют и мало кто на них вообще хоть как-то реагирует.
                                                                  0
                                                                  С учетом, что вроде как за какой-то промежуток боинг не получил ни одного заказа, а плюс ещё куча максов стоит внизу — то уже всё печально.
                                                                  0

                                                                  Про последствия уже сказали выше, напишу про "как надо". "Как надо" может быть достигнуто только обратной связью: самолёт упал, начали разбираться, претензии предъявили. Если кто-то скачал "СуперМегаЭКГ" из стора, занимался по нему и загнал сердце, то претензий быть не может. Или если из-за краша Хрома вы упустили выгоду, никто не будет разбираться и её возмещать.


                                                                  Мне вспомнились дискуссии на тему "Кто виноват, если робоавтомобиль без органов управления сбил человека?". Когда высказывались в смысле "разработчик/фирма-изготовитель автомобиля", отвечали "как можно!" и "никто не согласится писать автопилоты!". Ну, для самолётов и АЭС как-то пишут.

                                                                    0
                                                                    «Как надо» может быть достигнуто только обратной связью: самолёт упал, начали разбираться, претензии предъявили

                                                                    Жесть вообще. Надеюсь вы никакого отношения к разработке хоть скольнибудь критичных системне имеете. Представляю как вы бы объясняли это отставшися родственникам за тех, кто был в самолете, с вашим софтом написанным таким образом.
                                                                    «Я не виноват, мы просто дебажились на летящем самолете проде, других вариантов не знаем»
                                                                      +2

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

                                                            +2
                                                            Как я уже говорил, мы хорошо делаем программное обеспечение при условии, что последствия неудачи не имеют значения.

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

                                                                Даже в контексте сравнения с инженерами и строителями? То есть ясное дело что абсолютно безотказных систем не бывает. Но я бы не сказал что в перечисленных мною областях софт выглядит сильно «безалабернее» чем те же инженерные решения.
                                                                  0
                                                                  Вот ровно в пределах калькулирования — да. А всё стороннее — это грусть, печаль, тоска из тех же костылей и велосипедов.
                                                                0
                                                                automotive

                                                                Ага.
                                                                +2
                                                                image
                                                                  +1
                                                                  Эта лучше )
                                                                  image
                                                                    +3
                                                                    Бесплатно и качественно не бывает? А как же, например, Debian?
                                                                  –1
                                                                  А потому, что нефиг навешивать 150 тысяч висюлек и свистюлек на критически важные вещи. Я понимаю, когда у какого-нибудь Инстраграма один из ста фильтров не сработает — переживу. Но вот глюк в ПО Боинга я могу и не пережить.

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

                                                                    То есть получается, что целая Демократическая партия на довольно важный элемент своей инфраструктуры наскребла 60k и аж целых четырёх программистов? И начать разработку раньше чем за два месяца до дедлайна не сумела? И тестов в приближенных к боевым условиям не провела? Что-то мне подсказывает, что тут не в культуре стартапов проблема и не в спринтах.

                                                                      +1
                                                                      Насколько я понял речь идёт только о фракции из Айовы. И я бы не назвал это прямо уж «важным элементом инфраструктуры» :)
                                                                      0
                                                                      бывает хороший софт и плохой. Зависит от вменяемости руководителя проекта.
                                                                      В данном случае это были коммунисты.
                                                                        0
                                                                        Компания «Шэдоу» получила за разработку неработающего приложения 63 миллиона долларов.Основательница «Шэдоу» — политтехнолог Тара Маккгоуэн. Она же является женой Майкла Халла — главного стратега президентской компании демократа Пита Буттиджича, кстати, победителя кокусов в Айове.
                                                                        Казалось бы, причём тут коммунисты? Может вообще, лично Сталин виноват? Или Ленин?
                                                                        С большим основанием можно утверждать тогда, что во всем виноваты геи.
                                                                        0
                                                                        Если не говорить о критичном ПО, которое хоть как-то тестируется, сертифицируется…

                                                                        Все знаю, что происходит. Бизнес/маркетинг давит на программистов — закостыль тут, тут по-быстрому добавь фичу, а эту фичу надо к пятнице, мы уже закупили рекламу. Проблема безопасности? — Да забей, ерунда. У пользователя что-то не работает? Но у большинства же работает, не надо тратить на это время. Обратную связь от пользователей будем направлять индусам, которые ни за что не отвечают, или сразу в /dev/null. Может быть будем продавать адекватный сервис по нормальной цене? Не, давай лучше будем продавать дешевое гавно за дорого.

                                                                        На самом деле проблема глобальная и она находится над бизнесом. Бизнес лишь руководствуется существующими правилами и стимулами. Пока делать плохой продукт будет выгоднее чем качественный, так все и будет.
                                                                          0
                                                                          кто ж использует первую версию чего бы то ни было в ответственном процессе ??
                                                                          Вы видели первые версии самолетов? Или первые версии автомобилей? (Любой авто компании, которая только начала их производить)
                                                                            0

                                                                            Странно что до сих пор никто не написал про превращение разработки в инженерную дисциплину путём внедрения формальных методов.

                                                                              0
                                                                              Серъезная разработка давно уже инженерная дисциплина и вовсю применяет формальные методы.
                                                                              Наколеночные «сделай сам», перевязанные стяжками и синей изолентой — так же надежны, как и софт, написанный племянником (или индусом на аутсорсе), у которого дядя на откатах\госзаказах…
                                                                                +1

                                                                                Это каких, например?

                                                                                  0
                                                                                  Формальная спецификация
                                                                                  0. habr.com/ru/company/yandex/blog/471012
                                                                                  1. habr.com/ru/company/jugru/blog/455467
                                                                                  Формальная верификация:
                                                                                  0. habr.com/ru/post/400149 тут есть пример про микроядро seL4
                                                                                    +1

                                                                                    Мне интересно, как объяснить менеджеру внедрение TLA+ или аналогичного способа проверки спецификаций.


                                                                                    • Вы чем уже 2 недели занимаетесь?
                                                                                    • Да вот, пытаемся понять исполним вообще заказ или нет.
                                                                                      0

                                                                                      Мм… это же не постфактум надо, а заранее, и с цифрами: "у нас готова черновая спека, но есть шанс, что в ней могут быть серьезные нестыковки. Разработка займет 8 месяцев с учетом возможных рисков, перед началом мы предлагаем потратить еще 2 недели на создание формальной модели, чтобы выявить и исправить эти нестыковки заранее, что позволит разработать конечный продукт за 4 месяца"

                                                                                        0

                                                                                        Видимо, мне сильно не везло с заказчиками, в т.ч. внутренними. Большинство действую по принципу "Что тут думать, прыгать надо" и "Ну я тебе говорю!". Самых неадекватных отсеиваю, конечно, но остальными приходится работать.

                                                                                        +1

                                                                                        По приведенным ссылкам есть примеры и нахождения багов и сокращения кода во много раз (что сокращает расходы на поддержку), но очевидно, что не во всех проектах это надо считать обязательным — онлайн-магазин поделок бабы Вали переживёт низкое качество.

                                                                                  –1
                                                                                  Так много слов, чтобы сказать «попил бабла» :-)
                                                                                    0
                                                                                    Да все люди несовершенны. Плохо водят автомобили, плохо их конструируют и строят дома. Просто большинство этих ужасов видят только специалисты соответствующего профиля.
                                                                                    Это ошибка наблюдателя.

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое