Ранее на этой наделе (оригинальный пост был от 28 февраля) я сменил название сайта на Worse Than Failure (Страшнее провала). Многие читатели были недовольны новым названием и многие из вас удивлялись, почему из всех названий я выбрал именно Worse Than Failure. В конце концов, что же может быть страшнее провала? Вместо того чтобы рассказывать вам еще одну историю про какой-то конкретный провал, я поделюсь своими мыслями насчет того, почему в нашей индустрии существуют и будут существовать такие неописуемые случаи кретинизма, заставляющие нас восклицать What The F*ck, и почему столь многие из них на самом деле страшнее провала.
За прошедшие три года, которые я пишу этот блог, я видел некоторые из самых непотребных извращений в информационных технологиях когда-либо явленных миру. Черт возьми, да все мы их видели. В то время как виновником довольно небольшой части из этих катастроф является банальная некомпетентность новичков, очень многие просто не поддаются объяснению. Будто бы собрались вместе жутко толковые, невероятно образованные, с хорошим техническим воспитанием инженеры-программисты и порешили: «А давайте создадим худшую программу всех времен и народов!»
Взгляните на Дружественную к клиенту систему. Или Инструмент. Или на любую другую из бессчетного множества представленных здесь. Такие системы наша дорогая Паула Бин не смогла бы запрограммировать даже под страхом смерти. Нет-нет, для их разработки необходимо хорошенько пораскинуть мозгами. Так почему же люди со столь глубокими познаниями разрабатывают столь чудовищные системы? Элементарно, просто их не останавливают провалы.
Что за провал?
Как говорится, опыт - сын ошибок трудных. Это соответствует истине в любой области, от шахмат («никто не становится лучше выигрывая») до бизнеса («провал - это часть успеха»). Само собой, прежде чем кто-то сможет извлечь урок из своего провала, он сначала должен осознать, что потерпел неудачу. В большинстве случаев – Шах и мат! Банкротство! – все достаточно очевидно. А что же в информационных технологиях? Не настолько.
Согласно проведенному исследованию Standish Group о Доле успешных проектов, «84% проектов терпят неудачу либо встречают на своем пути серьезные трудности». Это совершенно противоречит общепринятому мнению, которое говорит нам, что большинство проектов в какой-то степени успешны и встречают на своем пути лишь несколько незначительных преград.
Хорошо это или плохо – вообще-то плохо – но, как только код выходит в свет и основная масса свежеобнаруженных багов исправлена, всё, можно праздновать! Все трудозатраты окупились и, несмотря на несколько задержек и марафонов по выходным, проект, наконец, обрел жизнь. Нет даже времени на чтение панегирика, надо уже скорей начинать следующий проект. Воспоминания о режущих ухо аргументах насчет плохого дизайна и кое-как налепленных припарках со временем угасают, и в головах многих людей проект становится успешным. Все верно, для тех, кто изначально разработал Дружественную к клиентам систему, она, несомненно, была успехом.
И это повторяется снова и снова. Консультанты, стоявшие за разработкой Дружественной к клиенту системы, системы, которая использует диаграммы Visio для определения своих рабочих процессов, считали ее успешной. Это значит, что они позаимствуют решения, полученные при разработке этого проекта, и будут применять их снова и снова. В конце концов, система родилась такой именно благодаря их предыдущим успешным проектам.
Ус-пех, сущ.: Все что угодно
Вспомните все те проекты, в которых вы играли ключевую роль, и которые дошли до промышленного использования. Ну и сколько из них вы считаете успешными? Бьюсь об заклад, что большинство людей ответят – все до единого. Для меня все определенно так и было. Я привык думать, что все информационные системы, над которыми я работал, были успешными. Нет, они не были совершенны – чего уж там, многие вообще можно было использовать с большим трудом – но они работали. Они в принципе делали то, для чего предназначались, и были приняты клиентом. Разумеется, они не были провалом, так?
Мы практически единственная индустрия, в которой слова успех и завершение являются синонимами. Если фундамент годовалого дома крошится, а крыша всюду протекает, неужели хоть кто-то назовет это успехом? Не смотря на то, что он был снят и уложился в бюджет, неужели кто-то без стыда хранит в своей фильмотеке Джильи (Gigli)? Конечно нет! Так почему же создаваемые нами продукты – сложные информационные системы, которые должны оставаться работоспособными, по меньшей мере, пятнадцать лет – должны придерживаться другого стандарта?
Теперь вспомните свои собственные проекты. Сколь многие из них могут поддерживаться кем-то с меньшими знаниями предметной области и более ограниченным пониманием структуры системы? Сколько из них, по вашему мнению, смогут продержаться хотя бы 15 лет? Готов поспорить, что их количество несколько меньше чем все до единого.
Рецепт провала
Ну и к чему мы пришли? Неужели нам действительно надо ждать окончания жизненного цикла системы, прежде чем мы сможем назвать нашу разработку успешной? Естественно! Однако мы можем признать провал гораздо раньше. Но только при условии, что мы хотим его выявить.
Мне потребовалось много, много лет для того, чтобы я, наконец, был готов признать, что несколько первых единолично мной разработанных систем были провальными. Каждое из этих приложений было хуже, чем предыдущее, и было поистине чудом, что третья по счету подобная система вообще заработала при промышленной эксплуатации. Разумеется, тогда я этого не понимал, но используемые техники были настолько отсталыми и ошибочными, что сами послужили бы отличным материалом для статьи на этом сайте. Когда-нибудь я даже ими поделюсь, обещаю.
В то время я верил, что ухудшающееся качество и возникающие при разработке трудности были следствием все большего усложнения каждой новой системы по сравнению с предыдущей. Но это было не так. Просто с каждой новой системой я становился все более плохим программистом.
Я не помню, как я вырвался из этого замкнутого круга, или когда я начал осознавать, что я облажался, но возможно это случилось в то время, когда мне удалось в первый раз взглянуть на эпическое, программное бедствие, сожравшее миллионы долларов, и задать себе вопрос, What The F*?
Путь страшнее провала
Путь, по которому я шел, был тем же путем, которым до меня прошли разработчики этого гигантского левиафана. Они считали любой законченный проект успешным. Они не были высокомерными (по началу) – просто таким образом они, как и все остальные, определяли успех: доведение до промышленной эксплуатации.
Вместо того чтобы понять, что их первые приложения были плохо спроектированы, плохо запрограммированы и скоро должны были потерпеть неудачу – как и должно всякому первому проекту – они ставили галочку, помечая их как успешные, и переходили к следующему проекту. И затем разрабатывали снова и снова. Еще больше. Еще чудовищнее. Еще дороже. Еще хуже. Все потому, что они считали сдачу проекта успехом.
Если бы только они признали свой провал раньше и извлекли из него соответствующие уроки, они бы никогда не стали виновниками столь широкомасштабной катастрофы. Воображая, что их прошлые проекты были успешными, они нанесли себе гораздо больший ущерб, чем им нанес бы провал.
Тьма в конце туннеля
Хотел бы я закончить эту статью на хорошей ноте. Впрочем, полагаю, я могу с чистой совестью заявить, что сделал все возможное для того, чтобы системы, которые я разрабатывал или руководил их разработкой, были сконструированы надлежащим образом и проработали как минимум пятнадцать лет (хотя мысли об этом до сих пор меня пугают). Но это, скорее всего уже ничего не изменит.
Наша индустрия движется гораздо быстрее, чем раньше. Жизненные циклы программ становятся короче и короче, а под постоянным давлением поставщиков «новых» технологий, многие разработчики ПО даже не понимают, что плохого в том, чтобы переписывать всю систему с нуля спустя всего несколько лет. Да что говорить, многие не утруждают себя перепроверкой кода по прошествии даже трех лет.
В заключение, я надеюсь, это не только поможет объяснить, что может быть страшнее провала, но и почему я так сильно люблю новое название. Я искренне надеюсь, что, несмотря на свое название, этот блог будет продолжать учить и развлекать посредством историй о «любопытных перегибах в информационных технологиях». А может быть даже поможет кому-то сойти с порочного пути, который страшнее провала.
Оригинал:http://worsethanfailure.com/Articles/What_Could_Possibly_Be_Worse_Than_Failure_0x3f_.aspx
