Даже если вы знаете законы разработки программного обеспечения
Сегодняшние решения — это завтрашние ошибки
Разработка программного обеспечения — это загадка, окутанная тайной и засунутая на спинку дивана, прилепленная к вареной конфете.
Приведенные ниже правила и принципы объясняют, почему создание программного обеспечения занимает больше времени, чем ожидалось, даже если мы знаем правила и принципы разработки программного обеспечения.
Разработка программного обеспечения идет вам навстречу, так что будьте начеку и будьте готовы к ударам.
Закон Хофштадтера
Закон Хофштадтера: это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание закон Хофштадтера
Разработку программного обеспечения обманывает упрощенный взгляд на требования, например. на высоком уровне все программное обеспечение кажется простым. На детальном уровне это становится сложным.
Самый простой способ для разработчиков придать реалистичность планам проекта — получить примеры того, сколько времени ушло на создание аналогичного программного обеспечения. Разработка программного обеспечения никогда не терпит неудачу в плане, всегда в исполнении.
- Это будет сложнее, чем вы думаете
- Это займет больше времени, чем вы думаете
- Это будет стоить больше, чем вы думаете
- Каждому нужно будет усердно работать, чтобы исправить все проблемы, которые произойдут
Закон Брука
«Добавление рабочей силы к позднему программному проекту делает его более поздним» Брукс
Когда проекты отстают, обычное решение состоит в том, чтобы добавить в проект больше разработчиков. Это часто может привести к дальнейшему отставанию проекта, хотя и стоит больше денег.
- Почему добавление большего количества людей к проекту не ускоряет его работу
- Как мы пытаемся ускорить ИТ-проекты и почему это не работает
Добавление рабочей силы к позднему программному проекту делает его более поздним. Фред Брукс
Добавление большего количества разработчиков влечет за собой накладные расходы на адаптацию, а затем добавляет накладные расходы на связь в проекте.
Чем больше разработчиков, тем больше шансов, что разработчики будут конфликтовать друг с другом.
Добавление большего количества разработчиков не определяет и не устраняет основную причину отставания проекта. Добавление большего количества разработчиков устраняет симптом, но может привести к дальнейшему отставанию проекта.
«девять женщин не могут родить ребенка за месяц». Фред Брукс
Ошибка планирования
Статья в Википедии Заблуждение планирования объясняет это как
склонность недооценивать время, затраты и риски будущих действий и в то же время переоценивать преимущества одних и тех же действий
Я видел ошибку планирования в работе над каждым программным проектом, над которым работал. Люди, создающие план, устанавливают самые оптимистичные сроки, обычно потому, что это время и стоимость, которые им нужны.
Разработчики программного обеспечения недооценивают сложность создания программного обеспечения, в то же время преувеличивая преимущества программного обеспечения.
На высоком уровне требования к программному обеспечению кажутся простыми, и только когда вы переходите к деталям, вы обнаружите, что это будет сложнее, чем вы изначально думали.
Разработка программного обеспечения никогда не терпит неудачу в плане, всегда в процессе выполнения
Закон Мерфи
Все, что может пойти не так, пойдет не так. "Закон Мерфи"
Чем больше времени, людей и требований вы добавляете к программному проекту, тем выше вероятность возникновения проблем.
Невозможно остановить все проблемы, ошибки и проблемы. Команды разработчиков программного обеспечения не могут остановить проблемы, но они могут быстро подготовиться и восстановиться.
Представьте, что ваши кошмары сбываются и происходит катастрофа. Ваши методы, процессы и стандарты разработки программного обеспечения должны обеспечивать возможность восстановления (например, система контроля версий, DevOps, документация, проверка кода, резервное копирование и т. д.).
Технические катастрофы не должны заставать разработчиков врасплох
Закон тривиальности
«То, что срочно, редко бывает важным, а то, что важно, редко бывает срочным». Дуайт Д. Эйзенхауэр
Программные проекты будут сосредоточены на тривиальном за счет важного. Мало кто заметит, что закон тривиальности приводит к провалу их программных проектов.
Все заняты программным проектом, заняты встречами, созданием отчетов, обновлением информационных панелей и сосредоточением внимания на неважных тривиальных моментах.
Закон тривиальности Паркинсона гласит, что сложные вопросы обсуждаются кратко, потому что их не понимают, в то время как тривиальные вопросы обсуждаются потому, что у каждого есть свое мнение.
Разработчики программного обеспечения могут с радостью переставить шезлонги на Титанике, пока корабль движется к гигантскому айсбергу.
Закон Грешема
Плохие деньги вытесняют хорошие деньги — закон Грешема
Закон Грешема — почему плохие разработчики вытесняют хороших разработчиков. Разработчики предпочтут создавать низкокачественный код, если вознаграждение за низкокачественный и высококачественный код будет одинаковым.
Закон Грешема гласит, что плохое поведение, если оно оценивается одинаково, вытеснит хорошее поведение. Это объясняет, почему некоторые разработчики выбирают путь наименьшего сопротивления и создают некачественный код, потому что лидеры ценят скорость выше качества.
Плохая практика заменит хорошую практику, если она стоит того же значения, например. если люди не получают дополнительного вознаграждения за хорошую практику, зачем им трудиться больше? Для разработчиков нет никакой выгоды или стимула создавать качественный код в программных проектах.
Вы получаете то, за что вознаграждаете, а быстрое и низкокачественное программное обеспечение — это то, что нужно проектам.
Плохие разработчики вытесняют хороших разработчиков, потому что люди, не являющиеся техническими специалистами, рассматривают разработчиков как товар, и основная разница заключается в цене. Они узнают, что дешевый вариант разработки программного обеспечения стоит больше?
Закон Паркинсона
Закон Паркинсона гласит
«Работа расширяется, чтобы заполнить время, доступное для ее завершения».
Разработка займет отведенное на нее время, если она реалистична, или опоздает, если оптимистична.
Закон Паркинсона также работает со стоимостью разработки. Обычно это заканчивается доступным бюджетом.
Принцип Питера
Принцип Питера поражает своей простотой и гениальностью. Википедия
Принцип Питера гласит, что человек, компетентный в своей работе, получит повышение до должности, требующей других навыков. Если у повышенного человека не будет навыков, необходимых для новой роли, он будет некомпетентен на новом уровне и не будет повышен снова — принцип Питера
Как работает принцип Питера в разработке программного обеспечения: разработчики и другие роли позволят разработчикам развиваться до тех пор, пока они не достигнут роли, в которой они не очень хороши.
Разработчиков повышают до руководящих должностей из-за их способности писать код и создавать программное обеспечение. Многие разработчики считают себя ужасными менеджерами и больше не получают повышения. Они застревают в роли, которая им не нравится и в которой они не очень хороши.
Посмотрите на неудачный проект, и вы увидите принцип Питера в действии. Будут слабые старшие разработчики, менеджеры и лидеры. Это люди, которые достигли своего уровня некомпетентности.
Разработчики доходят до уровня своей некомпетентности
Правило девяноста девяноста
Правило девяноста-девяноста через вики
Первые 90% кода занимают 10% времени. Оставшиеся 10% занимают остальные 90% времени — Том Каргилл
Последние 10 процентов доработки кода или программного обеспечения могут занять столько же времени, сколько и первые 90 процентов. Процентный прогресс — это иллюзия, потому что программа не закончена, пока она не закончена.
Вы не знаете, какие проблемы могут возникнуть и сколько времени потребуется для их устранения.
Это правило касается планов и смет. Разработка предполагает отсутствие проблем, ошибок или проблем, и они всегда случаются.
Разработчики должны быть осторожны, указывая процент выполненной или оставшейся работы. Это распространенный способ повысить ожидания и заставить вас сожалеть о том, что вы высказали свое мнение.
Никто никогда не забывает оценку, произнесенную разработчиком
Первый закон экологии: все связано со всем остальным
Код никогда не делает что-то одно
Экология имеет дело со сложными адаптивными системами и имеет сходство со сложностью кода. Читайте о законе экологии — Как четыре закона экологии помогают решать проблемы
Он отражает существование сложной сети взаимосвязей в экосфере: между различными живыми организмами, а также между популяциями, видами и отдельными организмами и их физико-химическим окружением.
Тот факт, что экосистема состоит из нескольких взаимосвязанных частей, которые взаимодействуют друг с другом, имеет несколько удивительных последствий.
Разработчики программного обеспечения обманываются простотой, забывают, что код взаимосвязан и зависит от других частей кодовой базы.
Когда вы изменяете сложную систему, это изменение будет иметь много эффектов, желаемых и нежелательных побочных эффектов. Когда вы меняете код в кодовой базе, есть изменения, которые вы хотите, и, возможно, другие изменения.
Большая кодовая база слишком сложна для того, чтобы один разработчик мог понять изменения, надеюсь, будут модульные тесты, чтобы убедиться, что остальная часть кода работает должным образом.
По мере роста сложности вы получаете Накладные расходы на рукопожатие — растущие проблемы сложности в разработке программного обеспечения.
Взаимосвязанные зависимости программного обеспечения недооцениваются и являются причиной ошибок, сложности и проблем. Капельная подача фич в Agile-разработке вызывает сложность и технический долг.
Мы упрощаем решения, потому что забываем о сложности кода и о том, что код редко делает что-то одно.
Качество побеждает скорость
Самый быстрый путь к производству – это качество
Разработка программного обеспечения предпочитает настоящее будущему. Они выбирают кратчайший путь, краткосрочные преимущества перед качеством.
Создавайте быстрый код с техническим долгом, чтобы создать иллюзию прогресса.
Качество — это кратчайший путь в разработке, оно сводит к минимуму сложность и уменьшает технический долг. Написать код просто, создать программное обеспечение сложно. Во время создания будут проблемы и изменения, пока будут обнаружены правильные требования.
Когда вы меняете сложную кодовую базу, это вызывает непреднамеренные эффекты (ошибки, изменения). Качество сводит к минимуму последствия изменений, это важно, потому что Разработка ПО — игра для проигравших. Команда разработчиков, которая может свести к минимуму проблемы, ошибки и проблемы, создаст больше программного обеспечения с меньшими трудностями.
Словить 22
Только сумасшедшие разработчики будут работать над большим проектом
Те разработчики, которые не просят работать над большими проектами, не сумасшедшие, и это лучший выбор для работы над большим проектом
Разработка программного обеспечения не имеет особого смысла, код создает ошибки, а код исправляет ошибки.
Добавление большего количества людей к проекту может увеличить его продолжительность и стоимость.
Уловка 22 разработки программного обеспечения и другие правила напоминают вам, что иногда в этом мало смысла, но мы должны продолжать двигаться вперед.
В какой-то момент в большинстве дней я убежден, что разработка программного обеспечения должна быть игрой для сумасшедших, и я должен быть одним из них.
