Як бюрократія в офісі впливає на якість коду [закрито]

Мене цікавлять історії, в яких офісна бюрократія безпосередньо вплинула на результат кінцевого якості .

Наприклад, друг просто сказав мені, що на попередньому робочому місці система управління версіями була настільки громіздкою, що програмістам не було дозволено створювати нові "модулі" (кореневі каталоги у вихідному дереві), не запитуючи дозволів у богів VCS. Результатом було те, що програмісти не бажали пройти додатковий бюрократичний крок, а замість належних компонентів своїх служб вони закінчили накопичувати незв’язану функціональність поверх існуючих модулів, навіть коли функціональність була віддалено пов’язана з поточним визначенням модуля чи назвою модуля був шлях у минулому. (не кажучи вже про перейменування модуля ...)

Мене цікавлять подібні історії офісної, оперативної чи будь-якої іншої бюрократії, які з часом, можливо, ненавмисно вплинули на якість програмного забезпечення

Мене цікавлять історії, в яких офісна бюрократія безпосередньо вплинула на результат кінцевого якості.

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

Тобто, не сама бюрократія, а конкретні, пов'язані з QA дірками в бюрократії впливають на якість коду під час експлуатації (випадково чи зловмисно.)

Однак особиста динаміка та офісна політика набагато більше винуватця поганого коду. Особиста динаміка передбачає відсутність професійної етики насамперед. Я насправді не купую аргумент про те, що люди пишуть поганий код, оскільки вони не знають краще або не пройшли належну підготовку . Я бачив, як люди, які не мають спеціальних ступенів, пишуть гідний код. Це стан душі та особиста справа організованості та ретельності.

Офісна політика відіграє ще страшнішу роль. Боси, які підштовхують не думайте, просто кодують мантру (хоча бувають випадки, коли ми повинні просто кодувати та відправляти та чистити тіла пізніше); розробники, які наполягають на наданні того, що, на їхню думку, є ідеальним кодом, навіть якщо зараз щось вийти з дверей - це суть; рецензенти коду, які є ** отворами; кубічні війни тощо. Ці речі посилюють проблемну особистісну динаміку. Поєднання обох проникає через будь-які тріщини в процесі (бюрократія) або їх відсутність, спричиняючи зрив у забезпеченні якості коду.

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

Бюрократія сама по собі рідко колись є винуватцем поганої якості коду. Я б сказав, що на якість коду та бюрократизм негативно впливає негативна особистісна динаміка та офісна політика.

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

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