О процессах и результатах

Привет, тора гой дневничок. Есть люди, для которых стакан наполовину пуст, есть люди, для которых он полон, а есть люди, которые увлекаются процессами.

Речь здесь пойдет не об Agile, хотя и его тут чучуть есть, речь скорее пойдет об известной в узких кругах фразе “ты же инженер” и “мы не из мрамора ваяем”. Начать, видимо, стоит c определений. По классической википедии, инженер - это человек, обладающий определенными знаниями, которые позволяют ему применять на практике научные знания чтобы причинить пользу человеку. Из чего следует, что продуктом работы инженера будет нечто (машина, программа, технология), которая причиняет пользу, как бы банально это не звучало.

С точки зрения программирования, инженер - это программист, который делает конечный продукт для потребителя. Будь то социальная сеть, или система управления ядерным реатором. Здесь можно развивать тему, какие продукты считать приносящими пользу, а какие нет - но это сильно субъективная штука, мы ее трогать тут пока не будем. Основное здесь то, что инженер обычно нацелен на результат, потому как именно результат есть целью инженерного процесса.

И вот с этого момента начинается определенный конфликт между инженерией как предоставлением результата, усилиями, затраченными на этот самый результат, и наебизнесом, с которым тесно связан этот самый Agile.

Простейший пример с двумя зданиями дает небольшой рассказ, как контора строила дом по Agile, ну там одна бригада построила девятиэтажку, вторая по тому же ТЗ построила пятиэтажку, потом пришел заказчик и сказал что он вообще-то хотел 14-тиэтажку, на что ему ответили - не вопрос, щас поставим кран и поднимем пятиэтажку на девятиэтажку. Ничего не напоминает?

И вот тут в переделаем кроется вот это самое зло, которое во-первых, не очень встраивается в традиционные практики традиционной инженерной деятельности. Ну в самом деле, нельзя сначала заложить фундамент для пятиэтажного дома, а потом передумать - и запилить четырнадцатиэтажку. Причем уложившись в бюджет.

А во-вторых, тупо бесит. Про “бесит” можно поговорить отдельно. Я вот лично не могу представить программиста, который, сделав кусок работы по одной спецификации - получив на следующий день указание “все переделать потому што мы тут чучуть забыли” - пожмет плечами и переделает. Единственный наблюдаемый вариант, когда такое возможно - это когда программист работает в НИИ Говна и Торфа, вообще не заинтересован в результатах своей работы - и ему по-большому счету, тупо похуй что делать.

Вернувшись к “бесит” - с одной стороны, это тупо бесит по причине - человек, который ставил тебе задачу, на самом деле хуй ложил и на тебя и на твою работу. Ну потому что “ты ж не из мрамора ваяешь”. Что есть очень справедливо для разных говноконтор, специализирующихся на прогибании под заказчика всеми удобными и неудобными способами. В частности и потому, что стоимость часа работы программиста намного дешевле того времени и геморроя, которые потребуется для согласования всех штук в ТЗ. А сбоку стоит еще 100 лавок, которые готовые за символические 100 долларов написать болгенос.

С другой стороны, это тупо бесит потому что ты потратил определенное время на реализацию этой штуки. Время, которое ты мог бы потратить на что-то более полезное и продуктивное. “Семь раз отмерь - один отрежь” - это не странная пословица из фольклора, это вообще говоря самое первое, о чем должен думать постановщик задач перед тем, как собственно эту задачу поставить.

Причем здесь Agile? А при всем, Agile - это культура непринятия или откладывания жизненно важных решений, неприменения мозгов и игра в процесс, когда программирование делается ради митингов, митинги делаются ради ретроспекшнов, и куча народу оказывается при деле, радостно распиливая бабло заказчика и запуская космические корабли в просторы большого театра в отчетах и графиках.

Ну и конечно же, любимая отмазка всех - это “ну нельзя же предусмотреть все, мы не из мрамора ваяем”. Этим, в частности, обуславливается отсутствие проектной документации чуть менее чем везде. Потому как для документации надо думать и планировать, думать и планировать в Agile не принято. Код, написанный сегодня - завтра будет выкинут на помойку или отрефакторен. Кстати, рефакторинг кода - это переписывание его без изменения функциональности. Ну то есть переливание из пустого в порожнее, про что написаны сотни книг и с чего кормятся тысячи коучеров - “давайте соберем прототип из говна и палок, а потом налепим сверху ведро и морковку”. Давайте, чо. Не из мрамора ваяем. Вы же инженеры, хуле.