Комментарии 92
Многое в статье верно, хотя частично и несколько утрировано, однако значительную часть проблем с недостаточным качеством выпускаемого ПО можно объяснить гораздо короче: в цикле "сделайте как-нибудь чтобы работало, а потом уже сделаем хорошо" зачастую не доходит дело до второго этапа, потому что к этому моменту уже требуются новые фичи.
Просто айтишники достигают предела некомпетентности
А в других сферах с этим куда хуже
Например терапевты в поликлинике убивают больше пациентов чем хирурги
Например терапевты в поликлинике убивают больше пациентов чем хирурги
Мне кажется это спорное утверждение. А терапевтов и хирургов одинаковое количество? И какой поток пациентов проходит через первых и вторых?
Идиотский комикс. При всём уважении к xkcd.
Цитата из кода боинга:
if (angle < 270.0) quadrant = 3;
else if (angle > 270.0) quadrant = 4;https://catless.ncl.ac.uk/Risks/31/57#subj22
Причина почему у Боингов проблема при посадке на некоторые полосы.
Так что, не надо доверять софту.
Не софту, а автору такого софта. Мой софт и плавает, и летает. Правда о проблеме 2038 года тогда НИКТО не думал. Я даже во сне не мог предположить, что мое ПО до него доживет.
Я отчётливо помню, что на волне обсуждения "проблемы 2k" упоминалась в том числе и "проблема 2k38"
Я даже во сне не мог предположить, что мое ПО до него доживет.Мне приходилось писать тесты для бизнес-логики с incomingParam < DateTime.Now. Входящий параметр я установил в 2049-01-01. Соответственно, через 30 лет тесты сломаются.
Кто знает, может, спустя все эти годы, некий программист увидит упавший билд, прочитает мой комментарий к тем тестам, и поставит мне, старику, бутылочку холодного сока.
Цитата из кода боинга:
Это не цитата из кода боинга, это лишь предположение одного человека о том что оно так устроено. Но да, проблема вида «все экраны отключаются при заходе на посадку с курсом 270 в таких-то аэропортах» весьма похожа
а то иначе не дай боже кто-то где-то сделает быстрее нас и всё
Кстати, это убеждение совершенно идиотское. «Кто первый встал — того и тапки» работает лишь в отдельных сегментах, притом с длиннющим списком условий. Чаще всего происходит наоборот — успеха добивается тот, кто позволил торопыгам первыми выкатить на рынок сырой продукт, а потом выкатил свой законченный.
В приведённом примере софт для голосования, это не открытый рынок, где все конкурируют, а скорее всего выбрали либо на конкурсной основе или на поле для игры в гольф подрядчика.
Из моего опыта, чаще на проект кидают каких попало людей и пару опытных. Проект делают по уму, с архитектурой, с юниттестами и прочим, как только заработала первая версия, умные ушли и остались кто остался. Юниттесты протухли, на тестирование нету уже бюджета, бюджета давно уже нету. И получается, как получается.
Еще хуже, если и умных на старт не нашлось. Все слышали про юниттесты и тестирование, но что это за зверь… каждому рисует его воображение разную картинку. От розового единорога, до кошмарного коня апокалипса. Там вообще хз что выходит из под пресса. Юнит тесты гоняют на общей базе данных, оптимизируют код на миллисекунды, а запросы к базе отрабатывают по 5 минут.
Короче про это все писали уже с 70-х годов, просто никто книжки не читает ))
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. Я думаю там пару человек потыкали пальцами в экран наверное, или вообще не смогли залогиниться.
На вопрос статьи можно ответить одним предложением. Почему мы пишем программы такого низкого качества? — Потому что бизнесу не нужно высокое качество, нам не ставят задачи сделать высококачественно, но ставят задачи сделать быстро, быстрее, еще быстрее и как можно быстрее.
Только есть нюанс — то что люди хотят/просят/заказывают на самом деле не всегда является тем, что действительно нужно )
Нужно кому?
Бизнесу нужно чего-то достичь — бизнес заказыает услуги, которые по его мнению помогут ему этого достичь, хотя на самом деле он может просто не знать что есть что-то эффективнее.
Приведите пожалуйста пример того, что заказывают люди и почему оно не нужно (кому?)
Не нужно людям для достижения их целей.
Детям не нужны четырехколесные велосипеды чтобы научиться кататься на взрослых, потому что проблема не педали крутить, а равновесие держать. И чтобы научиться держать равновесие лучше подходят двухколёсные велобеги.
Пример честно подслушан в интернете, и вроде как изначально приведён был Аланом Кеем в одном из его докладов, но я пока не выяснил в каком.
На самом деле, если задуматься, в жизни много таких ситуаций.
ОКей, но я так и не понимаю причем здесь высокое/низкое качество решения и быстро/медленно разработать?
Ваш вопрос имеет место быть, но он никак не влияет на то как (быстро/некачественно или наоборот) мы будет решать проблему клиента. Мы можем посоветовать клиенту лучшее решение, если оно есть в его вопросе, но всё равно нам придется дальше делать выбор как это решение сделать.
Так в том и дело, что из того что бизнес просит делать быстро(или даже некачественно), на самом деле не обязательно следует то, что ему хорошее качество не нужно.
Про быстро/качественно тоже есть нюанс, писал ниже — habr.com/en/post/488194/#comment_21275686
Просто больно смотреть как ребята, хорошие разработчики, дизайнеры и прочие хотят делать хорошо, а им за это дают по рукам.
Предлагаю голосовать ногами :)
Ну и нужен диалог, конечно, по возможности.
Ну и шутка про "семь красных невидимых перпендикулярных линий" тоже не на пустом месте появилась.
Платят за time to market — стараются делать быстро, платят за безопасность — стараются делать безопасно, всё разумно. И инструменты, и методологии, и стандарты есть под оба случая.
Другая беда с программными продуктами — с помощью технических средств пытаются решить чисто организационные. Я долго пытался понять, почему внедрение CRM/ERP и 1С — это почему-то IT, хотя вполне себе есть администраторы, документоведы, учётчики, кадровики, экономисты и бухгалтеры. Единственный ответ, который я смог найти, в том, что от специалистов этих специальностей никто не ждёт чуда (и даже высокой квалификации), а от айтишников до сих пор ждут, что те сделают всем внезапное хорошо, и пока что готовы айтишникам платить высокую зарплату, вместо того, чтобы более тщательно подбирать и контролировать традиционных специалистов, ну и платить уже им за работу.
Однако, если мы представим себе, что когда делали программу X, руководствовались именно этими принципами при принятии всех решений, и менеджерских и инженерных, то все равно остается пространство для того, чтобы программа дала сбой. Значит ошибки произрастают не только из нарушения этих принципов, а откуда-то еще.
А я вам скажу откуда — пока программы пишут люди, программы будут давать сбои. Человеку свойственно ошибаться. А компьютеры не смогут писать программы, потому что для этого человек должен будет им обьяснить, что писать. И мы опять вернулись к изначальной проблеме — человек несовершенен, и ему свойственно ошибаться. У попа была собака…
Мне кажется, на конкурентном рынке отсутствие багов может перевесить обилие фич.
Что произойдёт, если нарушены допущения такой экономической модели не работают?
Переводчики работают не лучше программистов, вычитывать хотя бы заголовки им некогда…
Потому что договорились не считать обманом потребителя продукт, в котором заранее заложено низкое качество.
Все эти AGILE/SCRUM — это коллективный договор о вранье.
Бизнесу врут, что его слушают и что он самый ценный в этом договоре, исполнителям врут, что они ценный ресурс. А на деле бизнес получает вечную разработку вместо конечного продукта. Программисты — жизнь с чувством вины, что костыли пустили в прод (но многое эти м довольны, кстати). А манагеры — простор для манипуляций и теми и другими.
Экономинка вранья и двойных стандартов.
Потому что договорились не считать обманом потребителя продукт, в котором заранее заложено низкое качество.
Все эти AGILE/SCRUM — это коллективный договор о вранье.
Бизнесу врут, что его слушают и что он самый ценный в этом договоре, исполнителям врут, что они ценный ресурс.
А я думаю проблема не в договоре а в его понимании, и в том под какими предлогами людям его продают. Причём продают не авторы договора(вспомнилось Agile is dead от одного из авторов манифеста).
Agile стал модным, его стали «покупать» под предлогом того что разработчики будут доставлять больше фич за то же время, только не вникали за счёт чего.
На самом деле доставлять можно не больше фич, а больше ценностей для пользователя, и не за счёт «фигак и в прод», а за счёт быстрого получения фидбека и лучшего определения направления, для доставки этих ценностей.
Вкратце, я думаю это извечная проблема того в сознаниях людей становятся плохими подходы после увиденных некорректных их реализаций и применений — ну не виноват микроскоп, что им гвози забивают.
Все эти AGILE/SCRUM — это коллективный договор о вранье.
С таким же основанием можно заявлять что «все эти UnitTests это коллективный договор о вранье» или «все эти ООЯП это коллективный договор о вранье».
Это всё инструменты и их можно использовать правильно или неправильно. Но только от того, что кто-то не умеет правильно пользоваться инструментом, сам этот инструмент плохим не становится.
P.S. А если взять конкретно AGILE/SCRUM, то сейчас этими словами называют всё что угодно. И даже вещи которые к AGILE/SCRUM вообще никакого отношения не имеют.
Постоянно слышу о том, что это не Agile/Scrum плохо, а вы его готовить не умеете. Забавно то, что никогда никто не говорит, как его правильно готовить, когда вообще начинать готовку и каковы критерии "нормальности". Просто все виды agile какие удалось повидать — были именно тем, чем написано — коллективным договором о вранье)
Причем в некоторых компаниях и рабочий и менеджерский люд и правда верили, что всё у них хорошо и что вот их аджайл правильный. Забавно то, что он был точно таким же как и везде, просто где-то "уверовали", а где-то нет)
Более того, я видел в одной компании, варили аджайл по-одинаковому в двух командах, занимающихся смежными проектами. В одной команде все прижилось и все у них было хорошо. И фидбек, и качество, и скорость, а в другой больше споров, четрехкратные задержки по срокам, нулевое качество софта и т.д. и т.п.
Забавно то, что никогда никто не говорит, как его правильно готовить, когда вообще начинать готовку и каковы критерии «нормальности».
Ну если ваш «аджайл» хоть где-то «кастомизирован» настолько что противоречит манифесту, то с вероятностью 99% он у вас уже ненормальный.
А давать вам рецепты по скраму на хабре это примерно как ставить диагноз по фотографии — ничего хорошего из этого скорее всего не выйдет. Вам нужен человек, который придёт к вам, посмотрит на ваши задачи и процессы и только тогда начнёт давать советы. И возможно что первое что он скажет это будет «для вас аджайл/скрам вообще не вариант». И в этом как бы тоже нет ничего ужасного.
Чем моё "мне так кажется" принципиально отличается от вашего "мне так кажется"?
Извините, но откуда вы взяли что я что-то считаю доказанным? Я пишу своё мнение и ни на что большее по умолчанию и не претендую. Я даже не собираюсь вот лично вас в чём-то убеждать.
Но вот если вы в свою очередь хотите чтобы я своё мнение поменял, то тогда вам действительно придётся доказывать мне что я ошибаюсь. Но вы пока просто приводите своё личное мнение и ничего более.
В одной команде все прижилось и все у них было хорошо. И фидбек, и качество, и скорость, а в другой больше споров, четрехкратные задержки по срокам, нулевое качество софта и т.д. и т.п.
Обязательное условие для аджайла: самоорганизованная команда мотивированных профессионалов. Судя по "больше споров" как минимум с самоорганизацией было не очень
Так нахрена самоорганизованной команде профессионалов какая-то хрень сбоку, с названием аджайл?) Да и в целом какая-то система организации работы? Ведь они сами себе самоорганизованы.
Так зачем выдумывать абсолютно всё с нуля если можно взять что-то уже имеющееся? И мало того что имеющееся, но к тому же уже с готовыми инструментами и/или интеграцией в распространённые инструменты.
Ну, из вышесказанного получается, что аджайл:
1) Невозможен нигде, кроме как в среде крутых сработавшихся специалистоа. Среди "индусов" (обычных линейных программистов) его не организуешь.
2) Практически бесполезен, т.к. буквально невоспроизводим. То, что в какой-то команде собрались близкие по духу компетентные люди — это дело случая, поэтому "внедрять аджайл" на предприятии — дело заведомо гиблое.
В итоге, мы опять возвращаемся к тому, что аджайл в большинстве своем, это какая-то лицемерная игра.
Видимо вы плохо понимаете образ мышления линейных чуваков, которые тянут свою лямку на галерах, а после работы забывают про неё до следующего дня. Им не грустно или типа того. Просто им пофиг на компанию, пофиг на продукт, пофиг на новые фичи) Они просто делают свою работу. Им не нужны похвала, довольные пользователи, красивые цифры. Плати зарплату, вот и все :)
У них нет цели стать начальником, им просто нравится пилить код, и шутить шутейки на кухне ') У них нет доли в компании, нет каких-то иных стимулов рвать жопу ради работы) У них вот семья, дочь во второй класс пошла, ипотека скоро закончится, ремонт вот в копейку влетает, родители уже что-то часто начали болеть. Им до всей этой беготни и амбиций просто нет дела :)
Так зачем, скажите мне, такому человеку аджайл?)
И это как бы совсем не про «рвать жопу ради работы» и какие-то амбиции, а скорее о том как писать нормальный и нужный код и чтобы тебе при этом не мешали какие-то левые люди. Как минимум так для меня лично выглядит «короткое содержание» аджайл.
Я не знаю к какой категории вы лично себя относите и насколько вы лично знакомы с различными процессами в целом и аджайлом в частности. Но вас например никогда не раздражали менеджеры, которые ни черта не понимают в программировании и при этом постоянно указывают вам как вы должны делать вашу работу?
чтобы тебе при этом не мешали какие-то левые люди
Весь аджайл построен на том, что тебе мешают какие-то левые люди. Мне мешают стенд-апы, мешают постоянно меняющиеся требования, мешает то, что надо "быстрее", а не "качественнее".
Мне, как человеку, который хочет просто решать задачу, водопад подходит больше всего :) Согласовали, зафиксировали, пилим потихоньку по плану :) Весь этот аджайл, мне, как рядовому сотруднику — НЕ НУЖЕН. Он нужен бизнесу, ведь ему приходится жить в вечном эпилептическом припадке смены требований :)
Я не знаю к какой категории вы лично себя относите и насколько вы лично знакомы с различными процессами в целом и аджайлом в частности
Да я самый обычный программист. Не плохой, но явно не из тех, кто занимается Rocket Science вещами С аджайлом видимо не знаком совсем, судя по тому, что у меня какое-то тотальное непонимание чего мне тут целую ветку пытаются донести.
Но вас например никогда не раздражали менеджеры, которые ни черта не понимают в программировании и при этом постоянно указывают вам как вы должны делать вашу работу
Мне кажется я не до конца понял вашу мысль. Что именно должен сделать/сказать менеджер, что я должен подумать, что он учит меня делать мою работу :) Ну, т.е. типа не будет же он тыкать пальцем в монитор и говорить: "вот тут переменную обнули!"
Наверное я очень везучий человек, но никогда не работал с такими менеджерами. Обычно PM ранее программировал, а если нет, просто доверял своей команде.
Весь аджайл построен на том, что тебе мешают какие-то левые люди. Мне мешают стенд-апы, мешают постоянно меняющиеся требования, мешает то, что надо «быстрее», а не «качественнее».
Вы конечно извините, но в каком месте это аджайл? Всё что вы перечислили однозначно противоречит тому самому «аджайл-манифесту». И это на мой взгляд как раз и есть самая большая проблема аджайла. То есть когда делают непонятно что и почему-то называют это «аджайл».
Согласовали, зафиксировали, пилим потихоньку по плану :)
И в каком месте это противоречит аджайлу? Более того если взять конкретно скрам, то это одно из основных правил этого самого скрама: во время спринта задания добавляются или изменяются только если абсолютно все в команде с этим согласны. А размер спринта выбирает опять же сама команда. Хотите можете хоть по полгода спринты назначить.
Мне кажется я не до конца понял вашу мысль. Что именно должен сделать/сказать менеджер, что я должен подумать, что он учит меня делать мою работу :) Ну, т.е. типа не будет же он тыкать пальцем в монитор и говорить: «вот тут переменную обнули!»
Ну я скорее о вещах вроде «на рефакторинг времени нет», «запилите быстро костыль, потом когда-нибудь переделаем», «юнит тесты не нужны» или наоборот «нам нужно 100% покрытия юнит тестами».
С аджайлом видимо не знаком совсем, судя по тому, что у меня какое-то тотальное непонимание чего мне тут целую ветку пытаются донести.
По тому что вы пишите похоже так оно и есть. То, что вы пишите, это скорее какой-то «аджайл курильщика». Так бы я лично тоже работать не хотел.
Весь аджайл построен на том, что тебе мешают какие-то левые люди. Мне мешают стенд-апы, мешают постоянно меняющиеся требования, мешает то, что надо "быстрее", а не "качественнее".
Аджайл бывает разным, но вы похоже больше о Скраме. Так вот, в Скраме левые люди мешать не должны, есть скрам-команда и всё. С "левыми людьми" взаимодействие команды регламентировано обычно и идёт раз в спринт (по дефолту две недели). Если члены вашей команды для вас левые люди, то команды у вас нет, а значит обязательное условие скрама не выполняется.
С самоорганизованной командой надо как-то взаимодействовать бизнесу. Аджайл — это типа архитектуры этого взаимодействия как REST, а скрам — типа протокола взаимодействия по этой архитектуре, типа HTTP
А почему вы решили что весь софт низкого качества? Я пишу софт для встроенных систем. Ошибка в моем коже может «бабахнуть» очень хорошо, поэтому софт из моей конторы выходит качественный. Перепровенный ревью, пятью разновидностями тестов. При этом написать 100 строк кода в день — это даже много. При этом работа по Аджайлу. И это работает.
Результат — много лет на рынке и хорошая репутация.
Вывод — там где надо с кодом все в порядке, где неважно, там всякое может быть.
Вывод — там где надо с кодом все в порядке
Боингу об это расскажите, или тойоте или другим компаниям, продукты которых критичны для жизней людей и в которых просто откровенный говнокод оказался…
Пока ваш личный пример больше похож на ошибку выжившего, чем на систему.
Боингу об это расскажите
Если падает самолёт, то обычно раскручивают цепочку и находят виноватого, фирмы рискуют деньгами и репутацией, разработчики в общем-то тоже. Если падает приложение, то многие это воспринимают это как норму, а для остальных есть EULA.
Как репутационные риски остановили Боинг от найма дешевых индусов для разработки софта?
И что толку от этих репутаций каких-то людей из Боинга, сотням погибших пассажиров и их семей?
Где тут вообще логическая связка обычными приложениями и EULA, если речь идет про «там где надо с кодом все в порядке»? Или в самолетах качество «не надо»?
С другой стороны баги какого-нибудь фейсбука мало кого интересуют и мало кто на них вообще хоть как-то реагирует.
Про последствия уже сказали выше, напишу про "как надо". "Как надо" может быть достигнуто только обратной связью: самолёт упал, начали разбираться, претензии предъявили. Если кто-то скачал "СуперМегаЭКГ" из стора, занимался по нему и загнал сердце, то претензий быть не может. Или если из-за краша Хрома вы упустили выгоду, никто не будет разбираться и её возмещать.
Мне вспомнились дискуссии на тему "Кто виноват, если робоавтомобиль без органов управления сбил человека?". Когда высказывались в смысле "разработчик/фирма-изготовитель автомобиля", отвечали "как можно!" и "никто не согласится писать автопилоты!". Ну, для самолётов и АЭС как-то пишут.
«Как надо» может быть достигнуто только обратной связью: самолёт упал, начали разбираться, претензии предъявили
Жесть вообще. Надеюсь вы никакого отношения к разработке хоть скольнибудь критичных системне имеете. Представляю как вы бы объясняли это отставшися родственникам за тех, кто был в самолете, с вашим софтом написанным таким образом.
«Я не виноват, мы просто дебажились на
Как я уже говорил, мы хорошо делаем программное обеспечение при условии, что последствия неудачи не имеют значения.
Возьмите какую-нибудь медицинскую технику, automotive или ПО для атомной промышленности и вы увидите что «мы» точно так же можем хорошо делать программное обеспечение и когда последствия неудачи имеют значение. Так что я бы всё таки не cтал бы так обобщать вот прямо на всех.
Так же и с этим голосованием — если оно правда было так важно, и от этого вот прям зависела политика всей страны, так может надо было сделать его на чём-то, что проверено 150 раз. Хоть на гугл формах, хоть киданием бюлетеней в урны. А то ведь наверняка попытались какие-то новейшие фреймворки нацепить на супер-крутые технологии разработки и деплоя. Вот и результат.
То есть получается, что целая Демократическая партия на довольно важный элемент своей инфраструктуры наскребла 60k и аж целых четырёх программистов? И начать разработку раньше чем за два месяца до дедлайна не сумела? И тестов в приближенных к боевым условиям не провела? Что-то мне подсказывает, что тут не в культуре стартапов проблема и не в спринтах.
В данном случае это были коммунисты.
Все знаю, что происходит. Бизнес/маркетинг давит на программистов — закостыль тут, тут по-быстрому добавь фичу, а эту фичу надо к пятнице, мы уже закупили рекламу. Проблема безопасности? — Да забей, ерунда. У пользователя что-то не работает? Но у большинства же работает, не надо тратить на это время. Обратную связь от пользователей будем направлять индусам, которые ни за что не отвечают, или сразу в /dev/null. Может быть будем продавать адекватный сервис по нормальной цене? Не, давай лучше будем продавать дешевое гавно за дорого.
На самом деле проблема глобальная и она находится над бизнесом. Бизнес лишь руководствуется существующими правилами и стимулами. Пока делать плохой продукт будет выгоднее чем качественный, так все и будет.
Вы видели первые версии самолетов? Или первые версии автомобилей? (Любой авто компании, которая только начала их производить)
Странно что до сих пор никто не написал про превращение разработки в инженерную дисциплину путём внедрения формальных методов.
Наколеночные «сделай сам», перевязанные стяжками и синей изолентой — так же надежны, как и софт, написанный племянником (или индусом на аутсорсе), у которого дядя на откатах\госзаказах…
Это каких, например?
0. habr.com/ru/company/yandex/blog/471012
1. habr.com/ru/company/jugru/blog/455467
Формальная верификация:
0. habr.com/ru/post/400149 тут есть пример про микроядро seL4
Мне интересно, как объяснить менеджеру внедрение TLA+ или аналогичного способа проверки спецификаций.
- Вы чем уже 2 недели занимаетесь?
- Да вот, пытаемся понять исполним вообще заказ или нет.
Мм… это же не постфактум надо, а заранее, и с цифрами: "у нас готова черновая спека, но есть шанс, что в ней могут быть серьезные нестыковки. Разработка займет 8 месяцев с учетом возможных рисков, перед началом мы предлагаем потратить еще 2 недели на создание формальной модели, чтобы выявить и исправить эти нестыковки заранее, что позволит разработать конечный продукт за 4 месяца"
По приведенным ссылкам есть примеры и нахождения багов и сокращения кода во много раз (что сокращает расходы на поддержку), но очевидно, что не во всех проектах это надо считать обязательным — онлайн-магазин поделок бабы Вали переживёт низкое качество.
Это ошибка наблюдателя.
Почему мы пишем программы такого низкого качества?