Пугающие строки

Порой в ПСМ встречаются моменты, которые не на шутку пугают. Например.

... нас чаще всего волнует не книга, и даже не содержание книги (сам книжный текст), а описанное текстом книги. Волнуют описанные в книге миры, не волнует сама красота слога (ну, разве что «особых ценителей», если речь идёт о беллетристике, письме ради письма). С программами то же самое: волнует описанный программой фрагмент окружающего мира, не волнует сама программа (волнует не больше, чем книга и её текст). Если у вас программа заказа химчистки, то вас волнует одежда, которая из грязной станет чистой, деньги, которые с вас спишут, варианты транспортировки вещей на чистку и назад. Программа волнует программиста, но это его личное дело: всех остальных волнует, как эта программа справится с собственно ситуацией химчистки, да и программиста тоже должно это волновать. Если программа будет шикарна как софт, но химчистка с ней будет невозможна — то это провал проекта!

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

Основная идея автора понятна и не вызывает возражений. Разумеется, код и книги/документация ценны не сами по себе. Важно то, о чем говорит документация, важно какую задачу решает софт.

В первую очередь.

Но далеко не в единственную.

Форма играет второстепенную, но все еще очень значительную роль. Как заказчик, приму ли я абсолютно верную документацию у тех.писателя, если от его косноязычия сводит зубы? Разумеется нет, и уволю его как проф. непригодного - разработанная им документация не решает своей задачи - она не доносит информацию до читателя из-за плохого языка, из-за неудовлетворительной формы. Цель заказчика - не получить верное описание, цель - быстро и эффективно доносить верное описание до адресатов.

И здесь форма очень важна.

Еще хуже дело обстоит с кодом. От слов, что программа - личное дело программиста, пробирает озноб. Разумеется, если программа хорошо написана, но не решает своей задачи - это провал. Но провал очевидный - такую программу не выпустят в прод. Явная очевидная проблема, которая будет оперативно решена. Программа же, которая написана ужасно, но свою задачу решает - гораздо более коварная проблема. Такая программа может (при очень плохих процессах) действительно выйти в промышленную эксплуатацию. Стать важной частью рабочего процесса организации. Тут начинается самое интересное: процессы не статичны, требования к ПО тоже постоянно меняются, нагрузка растет. И вдруг оказывается, что модернизировать плохо написанную программу может только ее автор - никому не по силам понять, что он наворотил в коде, который твердо считал "своим личным делом". Да и сам он уже понять может далеко не сразу. И не все. А часть вещей сделаны так, что даже понимая, он не может и отредактировать в адекватные сроки - надо все переделывать.

Как итог, потраченные в пустую деньги, время, нервы. А порой и разорившиеся предприятия.

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