ДОделывать или ПЕРЕделывать?

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

• Мы обсуждаем единую библиотеку для нагрузочного тестирования? Ну, мне сложно составить список того, чего я хочу, т. к. что хочу – то я у СЕБЯ уже сделал или доделываю. А вы уж там думайте... 
• SOAP UI мощный инструмент, но проще написать на коленке сервлет... 
• В этом нашем фреймворке много лишнего функционала (правда, я использовал его для решения только одной/двух задач), поэтому надо всё переписать заново...
• Система логирования? Мне же в проекте нужен минимум, напишу-ка я свою собственную...

Знакомо? А что получается в результате?

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

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

Самое главное достоинство такого набора - разнообразие видов. Борьба за выживание (т. е. за пользователя) помогает инструментам становиться лучше и эффективнее. Понятно, что для этого должны выполняться разные условия, например, фидбэк, наличие ресурсов для сопровождения и доработки инструментов и пр. А в первую очередь - нужна информация о том, какие средства в компании уже имеются, какими инструментами пользовались или разрабатывали коллеги. И в таком случае, при соблюдении условий, наличие выбора только в плюс, а более удобная/практичная/стабильная/и т.д. программа сама займёт нужное место благодаря естественному отбору.

Самый важный потенциальный недостаток набора - "размазывание" фич по инструментам. Ситуация, когда инструмент № 1 умеет делать А, но не умеет Б, и инструмент № 2 умеет Б, но не умеет А - согласитесь, это неудобно. Одно дело, когда оба инструмента являются сторонними - тут ничего не поделаешь, остаётся сетовать на такое недоразумение. Но другое дело - когда мы сами эти инструменты разрабатываем. Вот тут-то мы имеем отличную возможность не бросаться с шашками наголо в лобовую атаку на танки. Конечно, всегда интересно самому реализовать в коде какую-то функцию или попробовать силы в новом для себя направлении. Но скорее следует внимательно изучить все варианты, по возможности использовать имеющиеся утилиты, и только при осознанной необходимости приниматься за написание новой.

Понятно, что никакого жёсткого правила для определения, нужно ли писать новый или дорабатывать имеющийся инструмент, не существует. Логика, опыт и здравый смысл - вот единственные союзники в принятии решения. А если их не хватает - всегда можно попробовать обсудить тему с кем-нибудь из коллег.

В целом, мне думается, что следует стремиться к минимально необходимому количеству самостоятельно разработанных инструментов. Никогда и никакая компания не может неограниченно тратить ресурсы (напомню, рабочее время каждого девелопера - не его личная собственность, но ресурс компании-работодателя) на поддержание целой кучи софта, который не предназначен для продажи. А сопровождать одну утилиту в определённой функциональной области легче, чем 2/5/10.

• Если в силу каких-то причин невозможно использовать стороннее зарекомендовавшее себя средство для нагрузки - пишем одну библиотеку, которую сможем использовать в разных проектах. И новые фичи, реализованные в одном проекте, будут доступны и смогут пригодиться в другом...
• Сервлет, конечно, проще, но SOAP UI поддерживается командой профессиональных разработчиков, и с большой долей вероятности позволит нам решить не только имеющиеся, но и будущие задачи для тестирования web service'ов...
• Имеющийся фреймворк не нравится? Докажи целесообразность траты ресурсов на написание нового или молчи вечно...
• А что касается собственного логгера - по-моему, это уже классика жанра.

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

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

Буду рад выслушать другие мнения.

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

P. P. S. Ну, а поводом для опубликования здесь послужило "Первое правило жизни" из блога Макса Пастухова.