[spoiler]Capers Jones, ИТ-гуру, автор методологии оценки проекта по функциональным точкам, не одно десятилетие изучающий вопросы производительности программистов («высококачественное ПО недорого, если брать общую стоимость владения -- качественный продукт быстрее создавать и поддерживать, нежели низкокачественное ПО») накопил внушительную базу разнообразнейших метрик по десяткам тысяч ИТ-проектов, и на ее основе решил проверить известнейшие программистские законы.
Оригинал http://www.drdobbs.com/architecture-and-design/programming-laws-and-reality-do-we-know/240166164
Boehm's Second Law
Прототипирование (быстрое создание простой работающей модели, объемом примерно 10% от результирующей системы) заметно снижает ошибки проектирования и неточности требований.
Это верно для средних систем объемом 1000 ф.т. (десятки тысяч строк кода), но для крупных проектов в сотни раз больше сам прототип будет уже весьма сложен, поэтому тут лучше придерживаться спиральных подходов.
Brooks' Law
Добавление людей в запаздывающий проект затормозит его еще больше.
Опять таки, если в проекте пять человек, то добавление опытного сотрудника позволит завершить работу быстрее. Но если в проекте трудятся сотни программистов, и взаимосвязи в коде сложны, то такие проекты практически всегда (70-80%) не укладываются в сроки -- причины также общеизвестны, плохой контроль качества и вносимых изменений. И тут добавление новых людей только увеличивает сложность схемы взаимодействия и действительно еще более заменяет процесс.
Conway's Law
Любая часть программной системы отражает организационную структуру, которая ее реализует.
Это действительно так. Например, размер программного компонента примерно будет пропорционально соответствовать размеру назначенной на его реализацию команды. Типовой размер программистского коллектива, реализующего конкретную задачу -- 8 человек, но опасность в том, что крупные проекты декомпозируются до размеров команд именно такого уровня -- однако такой подход может быть неоптимален в отношении разработки общей архитектуры системы.
Cunningham's Law of Technical Debt
Непродуманные попытки сэкономить время или деньги непосредственно в процессе девелопинга в итоге приносят внушительные финансовые потери в формате "technical debt" (например, судебных претензий заказчика в связи с плохим качеством или отказом покупателей приобретать продукт).
Урезания ресурсов в ходе работ часто приводят к последующему дорогостоящему ремонту или к более худшим результатам, это факт. Так, 35% крупных проектов не завершаются в связи с плохим качеством, так как "technical debt" на повышение этого качества нулевой, а итоговые финансовые претензии подчас в тысячи раз превышают сэкономленный "technical debt".
Hartree's Law
В стартовавшем проекте время от сегодняшнего дня до окончательного завершения проекта -- всегда одна и та же константа
Для плохо спланированных проектов и работ «на коленке» это подтверждается, но конечно, если компания применяет эффективные методы раннего управления рисками, проект удается уложить в разумные сроки. Правда, таковых компаний всего 10%.
Окончание следует
