Всем привет!
Без труда не вытащишь и рыбку из пруда, труд сделал из обезьяны человека, терпение и труд все перетрут... И т.д., и т.п., ага. Но, в случае разработки этот метод не всегда хорош, а порой, даже опасен.
Парадокс? Есть немного. У проблемы есть 2 аспекта, каждый из которых имеет свои причины и несет свои последствия.
Первый основан на ошибках формирования метрик качества и производительности программиста. Да-да, старый добрый "индусский код" ярчайший пример последствий использования неправильно выбранных метрик. Кто не в курсе - это код, который получается, когда программисту платят за строчки кода или за размер исходников, что прямо стимулирует писать как можно больше кода, даже (а на самом деле, особенно) если он бесполезен.
И хорошо, если есть хоть какие-то системы контроля качества - например, стат-анализ, то откровенный бред можно заметить и принять меры. Но так бывает далеко не всегда, и в результате даже у крупных компаний внутри их продуктов встречаются "интересные" моменты.
А второй аспект имеет другую причину - собственно, трудолюбие. А, точнее, отсутствие некоторой доли ленивости.
Казалось бы, в чем проблема - разработчик старательно делал что-то, писал, отлаживал, иногда перерабатывал, результата добился нужного.. Хорошо же! Вроде как бы, да. А потом внезапно выясняется, что его труды плохо дорабатываются, причем даже не силами других ребят, а им самим же. И вот после анализа ситуации выясняется интересное.
Оказывается, вместо того, чтобы перед началом работы взять и хорошо подумать - построить хорошую архитектуру, спланировать работы, продумать методики внутреннего тестирования, позаботиться об инструментах - разработчик сразу начинал писать код. Некогда думать, кодить надо, ага. Ну и что, что временный инструмент очень уж временный, ну и что, что много собственной копипасты, так надо! И со временем экономия на архитектуре начинает проигрывать издержкам в процессе разработки, и это уже в рамках одной фичи.
Что делать, чтобы избежать такой ситуации? В тесном кругу я отвечаю на этот вопрос так - надо периодически останавливаться, осматривать результаты своей работы и спрашивать себя - "а не хе*ню ли я делаю?" А еще обращать внимание на количество рутины в своих действиях. Одно уникальной действие - хорошо, два - уже повод напрячься, три - надо автоматизировать, принцип DRY (дословно "не повторяйся!") никто не отменял. Тогда потом команда может страдать меньше.