Числопоклонничество и орднунг

Нет большего удовольствия, чем на выходных, в спокойной обстановке (жена с детьми у родителей) разгребать финансовую отчетность (cost centers) и реализовывать ее на кложуре.

Таблица 200х50 ячеек, кошернейшая, с логичным заполнением из бухгалтерской отчетности, понятно как делать, теорию категорий вспоминать не нужно, в MSDN индусский лазить не нужно, в придурочных опенсорсных крестико-либах копаться не нужно, выравнивать элементы управления в дизайнере GUI, чтобы не жгли глаза неровностями, тоже не нужно, интегрировать с чужими системами (почти) не нужно, писать инструкции по деплойменту не нужно, инсталляторы на дебильных языках писать не нужно.

Сиди себе чиселки из sql запросов через filter/map/reduce раскладывай да структуры данных придумывай, да алгоритмы проверяй, пропуская последовательности через различные пути вычислений.

Ничто так не бесит, когда всякие вспомогательные действия занимают большую часть времени и замедляют работу на порядок. Написал 10 строчек, а потом к ним 100 строк в баг-трекере (которые все равно никто не прочитает и не поймет), а потом еще и объясни каждому по разу, зачем это и как оно работает.

О допустимой сложности

Очередной раз уткнулся на работе в безумие.
Безумие заключается в том, что теоретически правильные методики работы приводят к разрастанию непонятного кода.
Теоретическая правильность заключается в DRY. Т.е. куски кода и данных, являющиеся отражением одних и тех же сущностей или потоков данных предметной области выносятся в отдельные модули, обобщаются, делаются универсальными и прочее.
Причем тут именно что не натягивание совы на глобус, когда "похожие" функции и данные насильственно обобщаются, а только те, где написание двух раздельных заведомо приведет к необходимости синхронной правки двух и более разных мест кода.

А возникающая непонятность - это то, что в результате один конечный результат работы зависит от десятков модулей, в каждом из которых функции высшего порядка посылают другие функции третим функциям, возвращающим функции, которые обрабатывают списки функций.
Это условно говоря, на практике там ничего сложнее "передать функцию-конвертор и параметры в обобщенную функцию и получить результат" нету. В паре мест есть reduce внутри reduce для сложной группировки, все это занимает 10-20 строк кода и спокойно целиком вмещается на экран.
Подобные вещи для меня являются достаточно простыми и самоочевидными. Даже в чужом коде (нормально написанном) понятно, как с таким работать: открываешь самую верхнюю функцию и начинаешь от нее идти по дереву вызовов, постепенно отсекая неинтересные ветки, пока не доберешься до нужной. Это даже в крестиках-жабах-дотнетах-питонах просто, а в функциональных языках с их лаконичностью и того проще.

А проблема в том, что потом это нужно объяснить коллегам. И тут начинается какая-то знатная хрень, потому что я объяснить не могу.
Для меня очевидно, что map/filter/reduce - это как 2+2, обработка последовательностей, на которой вообще вся эта функциональщина стоит, и что структура данных определяет вызываемые для нее функции и что общие функции и данные нужно выносить в отдельные модули, а не писать каждый раз заново одно и тоже. Но процесс раскладывания в уме ТЗ на эти базовые блоки и обратной сборки конечного результата из блоков - объяснению не поддается.
Писать же код в "понятном стиле", в том смысле, чтобы минимизировать сложность за счет написания в лоб, без зависимостей, не выделять отдельные функции для удобства чтения - это, по моему, какой-то совсем уже бред.