нет. Физический блокнот для чего используют?

а то, что у Вас карандаш под водой не пишет - явно не проблема карандаша

давай не путать дедлайны и date driven development и "контрольные точки и управление".

В творческом процессе ты можешь "совершенствовать" что-то до бесконечности. вместо "дат" в качестве ограничений прекрасно работают измеримые цели. Вместо "увеличить продажи" что может растянуться до бесконечности можно сказать "увеличить продажи на 5%". Это можно измерить и это будет сигналом к тому что "задача завершена".

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

Люди как правило не "ленивые сволочи которым лишь волю дай они нихера делать не будут". Это обычно следствие контекста работы (не понятно что делать).

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

отсутствие тестов и кривая архитектура приводят к вполне конкретным рискам/проблемам. И решать надо проблемы а не "как это без тестов".

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

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

нужно понимать какие проблемы решают тесты

отсутсвие формулировок не приводит к недопониманию и как следсвие путанице?

нужно. а еще нужно понимать что в зависимости от того какие тесты и какие варианты существуют. Людям очень удобно иметь 3-4 инструмента на все случаи жизни даже если их есть 50

не те формулировки возможно ищешь)

или не с той стороны цепочки строишь

я лишь говорю что надо от проблем идти к решениям а не пытаться от решений (код) выйти на часть проблем

разумеется

но есть такая штука, как дальновидность. И понимание, что одно решение повлечет за собой 2 задачи, а второе решение 15 задач

например - тесты не решают никаких проблем если основная проблема - непредсказуемость реакции системы на изменение. Тесты закрывают только "известные" проблемы. А потому если архитектура и декомпозиция пошла по звезде никакие тесты не помогут

конечно

Но добавление фичи без тестов приводят так же к тому, что нужно вносить правки еще в 4 модуля

а это уже 5 задач, вместо одной

важно понимать что эта дальновидность основана на предположениях и надо уметь искать опровержения этим предположениям. Люди же чаще пытаются найти "подтверждения" и часто попадают в confirmation bias