Список проголосовавших за комментарий "Ошибка ваша в том, что исправление бага возвращает назад. Исправление бага придвигает вас к правильно работающей программе. Это как движение к идеалу, который, может быть недостижим, но ведь двигаться к нему все равно надо !<br/> Меня мотивирует вести журнал багов. Как только случилось что-то нехорошее, или даже то, что кажется подозрительным, записать это в систему баг-трекинга (но когда один работаешь, то проще в какую-нибудь табличку; мне самому в итоге лучше всего писать это в Mindjet). Критические баги надо исправлять сразу, остальные могут и подождать. Периодически в эту табличку нужно заглядывать и брать один из багов на ликвидацию.<br/> Еще хороший прием - тотальное логгирование. Пусть роботы пишут по несколько ГБ текстовых логов в день, какая проблема, ужмете их раром и перенесете в папочку на будущее. Но когда ошибка случается, чаще всего вся информация, нужная для ликвидации бага уже там содержится.<br/> Иногда информации для ликвидации багов в текстовых логах недостаточно и понять, что к нему привело невозможно. В таком случае можно сделать еще сообщений в логах и при следующем появлении этого бага уже станет понятнее.<br/> Когда исправляешь баг — переносишь его из своего списка в другой список «выполнено». Периодически заглядывать нужно и туда. Баг казался неисправимым, проявлялся непредсказуемо, целый год мешал жить, а потом смотришь — он в разделе «устранено». Это дополнительная мотивация.<br/> Ну и, конечно, программы надо стараться писать так, чтобы баги было проще исправлять. Это и архитектура, и комментарии в коде и различные проверки того, что «не должно было случиться никогда».<br/> Еще прием — исправлять один серьезный баг и тут же один мелкий. И хоть все системы тайм-менеджмента учат сначала заниматься срочными и важными делами, потом важными, а потом уже всеми остальными, но если мелкие баги накапливаются, то они начинают мешать жить с невероятной силой и мешать отлавливать более крупные. "