Статья Haste Makes Waste вообще о финансах, но начинается она с очень интересного исследования из мира биологии. Ученые брали две одинаковые группы мальков и помещали одну - в слишком холодную, а другую - в слишком теплую воду. В результате, мальки из холодной группы росли немного медленнее среднего для такого вида рыб, а мальки из теплой группы - немного быстрее. Затем мальков из обоих групп помещали в стандартную для них среду и со временем скорость их роста уравнивалась. Но на этом эксперимент не заканчивается! Оказывается, рыбы из холодной группы в итоге жили на 30% дольше среднего, а рыбы из теплой - на 15% меньше. А объясняется такая разница в продолжительности жизни тем, что ускоренный рост на ранних этапах формирования организма отнимает ресурсы у других не менее важных процессов - поддержки и восстановления существующих систем. И наоборот - замедленный рост позволяет больше ресурсов направить на поддержку и восстановление органов. Это все здорово и интересно, но причем здесь software development, спросите вы? А при том, что вероятно эти выводы можно экстраполировать на разработку сложных систем, особенно - разработку с нуля. Если допустить, что у нас есть две примерно одинаковые группы разработчиков делающих два примерно одинаковых проекта, и одна их групп топит за скорость поставки фич (экономя на рефакторинге, тестах, code style, observability, CI/CD и прочих вторичных вещах), а вторая - за качество процессов, то вероятно на первых порах первая группа будет продвигаться в продуктовой разработке намного быстрее, а вторая - намного медленнее среднего по больнице темпа. Но как показывает эксперимент с мальками, при помещении их в одинаковую среду со временем скорость роста уравнивалась в обоих группах. В случае разработки же зачастую определяющих фактором является степень сложности и успешность управление ей. Так как умственные ресурсы разработчиков в обоих группах конечны, а менеджмент всегда топит за скорость заработки фич, то рано или поздно оба проекта окажутся в нормальной среде с примерно одинаковым балансом фиче-делания и рефакторинга & co. Но моя гипотеза состоит в том, что проект первой группы загнется под весом неконтролируемой сложности намного раньше, чем проект из второй группы. В то время, как выработанные медленной группой на начальных этапах подходы и практики позволят второму проекту гармонично расти без саморазрушения из-за детских травм. Т.е. в долгосрочной перспективе неторопливый старт выигрывает. Если конечно у проекта планируется долгая жизнь, но это уже совсем другая история... 😉