Как офисная бюрократия влияет на качество кода [закрыто]

Мне интересны истории, в которых офисная бюрократия оказала непосредственное влияние на конечный результат качества кода .

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

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

Мне интересны истории, в которых офисная бюрократия оказала непосредственное влияние на конечный результат качества кода.

Я не думаю, что бюрократия так сильно влияет на качество кода, как личная динамика и политика офиса. Бюрократия имеет отношение к процессу. Когда существующий процесс выполняется ненадлежащим образом (или используется отрицательно ... см. Далее ниже), он потенциально может отрицательно повлиять на способность к доставке или реагировать на внезапные изменения. Однако отсутствие процесса окажет определенное и существенное влияние на качество кода. Или, если быть более точным, процесс, который не управляет качеством кода (также интерпретируемый как отсутствие качества кода), влияет на качество кода.

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

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

Офисная политика играет еще более ужасную роль. Боссы, которые толкают « не думай», просто кодируют мантру (хотя бывают случаи, когда мы должны просто кодировать, отправлять и очищать тела позже); разработчики, которые настаивают на том, чтобы предоставлять то, что они считают идеальным кодом, хотя получение чего-то на улице сейчас имеет существенное значение; рецензенты кода, которые ** дыры; кабельные войны и тому подобное. Эти вещи усугубляют проблемную личную динамику. Сочетание этих факторов просачивается через любую трещину в процессе (бюрократия) или ее отсутствие, что приводит к нарушению контроля качества кода.

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

Бюрократия сама по себе редко бывает виновником плохого качества кода. Я бы на самом деле сказал, что на качество кода и бюрократию негативно влияют негативная личная динамика и офисная политика.

Я перестал работать над некоторыми конкретными модулями в Проекте, потому что рецензент кода был Smart A $$

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