Теория разбитых окон. Может быть, вы слышали про это? Если вдруг нет, то это весьма спорная теория то ли из криминалистики, то ли из урбанистики. Что если в доме или в районе есть хотя бы одно разбитое окно на виду, то потом незаметно не останется ни одного целого. Или если брошен один фантик мимо урны, то потом обязательно улица превратится в нелегальную свалку. Причина (предположительно) в том, что человек видит "бить окна можно", следовательно не будет себя останавливать от плохих злодеяний. А, мол, когда всё вокруг чисто/аккуратно, как в музее, то как-то даже пылинку оставить стыдно. Даже если ни одной урны нет (частая история в Дублине, кстати), положишь мусор себе в сумку/рюкзак и выкинешь потом у себя дома, но никак не на улице. Не будем разбирать, правда это или нет. Думаю, куча допущений, нюансов. Звучит "слишком простым" объяснением сложных вещей, вот. Но совершенно точно в разработке программного обеспечения есть аналогичная вещь. Я это на себе явно ощутил. Пришёл два с половиной года назад в Технологическую Корпорацию. И увидел ЭТО. Много, скажем мягко, "спорных решений". Много каких-то незакрытых уязвимостей, нестабильностей, нечитаемого кода, лапши всякой. И это меня скорее обрадовало. Почувствовал себя нужным (наивный). Ну, то есть если бы было всё идеально, мы бы быстро стали безработными, да? На самом деле нет, есть бизнес-задачи. Есть новые продукты, есть новые рынки, которые надо осваивать. Но это скучно... разбираться в нетехнических вещах, как-то пытаться понять требования акционеров, которые сами не знают, чего хотят. И постоянно меняют мнение. В ответ на эту вроде бы есть agile manifesto, умели бы всеми этими лучшими практиками правильно пользоваться все, было бы хорошо... Ну и всё равно это не серебряная пуля. Хотя без agile практик мы бы все наверное вообще не смогли работать. Другое дело - существующая работающая система, но работающая с явными понятными ошибками. Слишком медленно. Или с известными уязвимостями. Или слишком медленный процесс сборки. Или тестирования. Или недостаток этого тестирования. Недостаточная гибкость кода для быстрого внесения изменений (вместо пару часов строчка кода попадает в жизнь спустя пару недель по разным причинам). О, одно из моих любимых: недостаточная похожесть тестовых сред (stage/dev) на живую (prod/live). Или какая-то шаманская магия, которую необходимо провернуть чтобы новый инженер установил у себя рабочую среду (то, что можно и нужно упростить буквально до одной команды). В общем, очень многие вещи были сделано "не оптимально", я точно знал как лучше (опыт предыдущих лет в предыдущих компаниях говорит). К сожалению, мало что удалось сдвинуть с мёртвой точки. А хуже всего то, что эти усилия особо не измеряются и не ценятся. Я готов (был) смириться с тем, что в конкурентной среде в погоне за прибылью компании важнее осваивать новые рынки и быстрее продавать новые продукты (то есть зарабатывать деньги), чем оттачивать качество. Да и улучшать можно до бесконечности, часто это вредная затея. Особенно когда стоимость изменений правда высокая. Другое вопрос, что если одно окно "уже разбито", можно его, допустим, не трогать (пометить ленточкой), но не разбивать новые... То есть новые проекты/сервисы/приложения/продукты запускать, не повторяя старых ошибок. Увы, но это не работает. Больнее всего смотреть на то, как "разбивают новые окна", в тот самый момент, когда тебе всего лишь руку было протянуть, чтобы это остановить. Вспомнилась статейка 2019 года не работайте в плохих проектах. Смысл похожий. В самом деле, не работайте. К сожалению, грязную работу (как бы она не была важна и впоследствии помогала бы и заработать денег и сэкономить и избежать репутационных издержек) не ценят, так как плохо умеют измерять. Или просто не хотят. @emerald_isle