Однажды исследователи взялись за выяснение причин, почему в некоторых районах города среди расположенных рядом зданий одни остаются ухоженными, а другие превращаются в заброшенные и тёмные развалины. Результаты этих исследований привели к появлению теории эффекта разбитых окон.Согласно этой теории, появление хотя бы одного разбитого окна, которое не заменяется в течение достаточно большого срока (допустим, больше одной-двух недель), создаёт высокую вероятность, что вскоре будет сломано и следующее окно, а затем ещё одно (и так далее), что в итоге приведёт к заброшенности всего здания.
Даже те люди, которые никогда бы не разбили окно ухоженного здания, вполне могут взять и кинуть камень в окно здания, в котором уже и так множество разбитых окон.
У сотрудников или жителей этого здания возникает чувство заброшенности. Они перестают следить за его чистотой, начинают мусорить. Когда здание становится достаточно заброшенным, те, кто его населял, покидают его. Такое здание может стать местом, где собираются бомжи.
В одном эксперименте никем не используемый автомобиль стоял нетронутым в течение нескольких месяцев. Но, как только было сломано одно окно, автомобиль за считанные часы разобрали по частям и перевернули вверх-ногами.
Так же к этой теории можно отнести появление мусора на улицах. Когда человек видит, что вокруг валяется мусор, ему и самому гораздо проще выбросить ещё что-нибудь, нежели ждать встречи с мусорным ведром.
Используя эту теорию, полиция Нью-Йорка стала активно пресекать даже мелкие проявления незакония (к примеру, граффити на стенах) для избежания крупных.
Говоря в общем, применить эту теорию можно к огромному количеству аспектов нашей жизни.
Как это связано с программированием?
Напрямую. Если оставлять «разбитые окна» в дизайне приложения или в самом коде, у программистов при написании последующего кода в голове проходят мысли вроде «Система написана небрежно. Если я и этот участок кода напишу небрежно, хуже не станет». Я был свидетелем подобного мышления у самого себя и у большого количества других программистов. В результате система превращается в скопление небрежно-написанного кода, и ситуация со временем только ухудшается.
Чаще всего, это приводит к тому, что команда увольняется, оставляя после себя код, вселяющий ужас в последующие поколения программистов, которые, в свою очередь, либо предлагают переписывать весь код, либо, если это не удалось, не засиживаются в этой компании и довольно скоро увольняются.
Переписывать код в сильно запущенном случае — единственный выход. Вполне возможно, что его не стоит переписывать полностью и с нуля, но постепенное переписывание способно исправить ситуацию к лучшему. Иначе проект со временем превратится заброшенную глыбу кода (если, конечно, проект не «одноразовый»).
Кстати, чаще всего такому, казалось бы необходимому, исправлению ситуации препятствует именно менеджмент. Вот пример их суждения: «все программисты готовы критиковать код предыдущих программистов и/или вечно доводить его до идеала».
Исправление сложившейся ситуации со временем становится только дороже: чем больше кода написано, тем больше его переписывать и тестировать. Поэтому предпочтительнее восстанавливать «разбитые окна» сразу, как только они замечены, чем доводить до переписывания кода.
К тому же, уважающий себя толковый программист, стремящийся к развитию, не будет работать над проектом, скатывающемся прямиков вниз из-за разрушения «разбитыми окнами», из-за возникающего ощущения деградации. (Чаще всего, это не просто ощущение, и, даже если это и не деградация, то определённо не развитие.) В то же время, посредственным программистам практически всё равно на качество кода. В результате того, что толковые программисты уходят, а посредственные остаются, сформировавшаяся команда будет состоять из этих самых посредственных программистов.
Распространённая ошибка менеджмента — считать, что именно «слабые» программисты не выдерживают работу над подобными проектами, от чего и уходят, а оставшиеся — «сильные». Но на деле, чаще всего, всё обстоит как раз наоборот.
Что же делать?
Не оставляйте «разбитых окон» в проекте. Встретив их, тут же предпримите какие-нибудь действия по их исправлению. Даже бездействие в данном случае может привести к весьма неприятным последствиям.
Источники
- Wikipedia: Fixing Broken Windows (фотография оттуда же);
- The Pragmatic Programmer: From Journeyman to Master;
- Собственные опыт и знания.
