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

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

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