Про лапки 🥰

В статье по дизайну я упомянул design stamina hypothesis. Гипотезу, что у хорошего дизайна кривая стоимости изменений гораздо более плоская, чем у плохого. Простым языком: если код - говно, то менять его тупо дороже, простите меня за мой французский.

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

Или всё-таки умеем?

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

Не хочу долго мусолить методы сравнения, но из уважения к читателям укажу основные метрики, которые мы знаем:

- строчки кода
- сторипоинты
- тест-кейсы
- количество фич
- соотношение новой работы и остальной работы
- business value
- dora-метрики
- интуиция.

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

Дурацкая импотенция

Вот эта вот скорость - это далеко не единственная штука, с которой у нас есть проблемы. Мы отвратительно оцениваем объём работ, плохо прикидываем business value той или иной фичи, ужасно справляемся с big upfront design, простите мне этот англицизм. И, если кто-то утверждает, что он все это умеет, то он или гений, или заблуждается, или просто врёт.

Про целеполагание

И во всей этой импотенции обязательно надо понимать: цель измерений-то какая?

Вот у вас есть быстрая команда, которая фигачит в два раза быстрее остальных. А толку, если она фигачит не туда? Это прям такая классика, когда 2/3 разработанных фич пользователями либо используются крайне редко, либо не используются вообще. Есть даже название такому софту: bloatware.

То же самое касается и оценки объёма работ. Вот вам дали ТЗ. Допустим, сами пользователи дали. Вы оценили: через год будет готово. Ну вот даже если вы прям угадали, и через год все готово. Вот даже если у вас супер быстрая команда, которая сделала это в 2 раза дешевле остальных. Ну вы все равно упираетесь в тот факт, что даже сами пользователи не знают, что им реально надо. И через год у них за пол стоимости есть функционал, 2/3 из которого можно было не делать.

Дежурный пинок водопада

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

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

К чему я это все?

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

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

Куда копать дальше?

Три года назад, когда моя голова была забита всей этой экстремалкой, CD и прочим аджайлом, вот этот доклад для меня перевернул все. Gojko Adzic - самый главный амбассадор борьбы с работой не туда, поэтому рекомендую ознакомиться с его работами.

Эти же идеи транслирует и Эрик Райс в своём Lean Startup. У него есть одноимённая книга, но для быстрого ознакомления рекомендую вот этот доклад.

Ну и из всей горы экспертов, советов и методологий наиболее положительно, конечно, выделяется DORA со своими Accelerate и State of Devops. Эти  просто померили, что влияет на успехи компании и предикторы этих успехов, а что - нет. Никаких вам умозрительных пальцесосаний, сухая конкретика.

Привет!

Молния! ⚡️⚡️⚡️

В Postgres 18 готовят поддержку property graph query language! А в Oracle 23 она уже есть.

Пример

SELECT DISTINCT id, fof_parents, details 
FROM GRAPH_TABLE(
    characters
        MATCH (a IS node WHERE a.name='Samwise Gamgee')-[x IS relationship WHERE x.type='friend']->
                      (b IS node)-[y IS relationship WHERE y.type='friend']->
                      (c IS node)<-[z IS relationship WHERE z.type='parent']-
                      (d IS node)  
        COLUMNS (d.id, d.name as fof_parents, d.details as details)
);

id |  fof_parents   |        details        
----+----------------+-----------------------
 2 | Bilbo Baggins  | {"species": "Hobbit"}
 4 | Hamfast Gamgee | {"species": "Hobbit"}
 7 | Arathorn       | {"species": "Human"}
 9 | Thranduil      | {"species": "Elf"}
11 | Gloin          | {"species": "Dwarf"}

Источник примера

И дев-сборку можно уже руками потрогать.

Кажется, это наконец-то решит проблему выборки иерархичных данных (aka json-ов) из реляционных СУБД.