14 программерских "правил", или как запороть проект

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

1. Проще изменить спецификацию программы, чтобы она ей (программе) соответствовала, чем наоборот.

2. Какие бы супер интересные функции вы не задумали реализовать впоследствие после поставки программы, можете о них забыть. Как только проект принимается заказчиком, он переходит в окончательное состояние.

3. Эволюция программных продуктов неизменно сохраняет стремление к использованию всех доступных на машине ресурсов.

4. Пока на разработку программы не будет затраченно хотя бы 6 месяцев, самые страшные и вредоносные ошибки не будут выявлены.

5. Трудозатраты, необходимые на исправление ошибки, возрастают со временем экспоненциально.

6. Просматривая написанный вами код, который вы не открывали месяцами, вы будете уверены, что написал его кто-то другой.

7. Внутри каждой маленькой программы живет большая амбициозная программа, безуспешно пытаясь вырваться наружу.

8. Чем раньше вы начнете процесс написания кода относительно начала проекта, тем больше это займет времени.

9. Плохо спланированный проект реализуется в 3 раза дольше ожидаемой продолжительности. Хорошо спланированный проект реализуется всего лишь в 2 раза дольше.

10. Подключение программистов к опазывающему по срокам проекту превращает его в совсем-ни-в-какие-сроки-не-укладывающийся проект.

11. Программный продукт никогда не бывает готов меньше, чем на 90%, и больше, чем на 95%.

12. Если вы автоматизируете хаос, вы получаете автоматезированный хаос.

13. Создайте программу, которую сможет использовать даже дурак, и только дурак и будет её использовать.

14. Пользователи никогда не знают, чего они на самом деле хотят от программы, пока не начинают её использовать.

- надергано с буржуйских блогов