Помнится, где-то в одной книге о программинге было описано "правило одной неизвестной"
То есть, если берешься за проект — убедись, что там есть только одна неизвестная тебе величина. Неизвестный тип задачи, новая незнакомая команда, новая технология, новая методика управления и т.п. Если неизвестных больше одной — шансы на фейл растут по экспоненте.
Где это было описано, кто-нибудь помнит?
Здравствуйте, Klatu, Вы писали:
K>Помнится, где-то в одной книге о программинге было описано "правило одной неизвестной" K>То есть, если берешься за проект — убедись, что там есть только одна неизвестная тебе величина. Неизвестный тип задачи, новая незнакомая команда, новая технология, новая методика управления и т.п. Если неизвестных больше одной — шансы на фейл растут по экспоненте. K>Где это было описано, кто-нибудь помнит?
Здравствуйте, Klatu, Вы писали:
K>Помнится, где-то в одной книге о программинге было описано "правило одной неизвестной" K>То есть, если берешься за проект — убедись, что там есть только одна неизвестная тебе величина. Неизвестный тип задачи, новая незнакомая команда, новая технология, новая методика управления и т.п. Если неизвестных больше одной — шансы на фейл растут по экспоненте. K>Где это было описано, кто-нибудь помнит?
Что-то похожее было написано в книги peopleware. Там правда говорилось, что при изучении новых технологий/подходов не желательно все сразу в проекте использовать.
Здравствуйте, Klatu, Вы писали:
K>Помнится, где-то в одной книге о программинге было описано "правило одной неизвестной" K>То есть, если берешься за проект — убедись, что там есть только одна неизвестная тебе величина. Неизвестный тип задачи, новая незнакомая команда, новая технология, новая методика управления и т.п. Если неизвестных больше одной — шансы на фейл растут по экспоненте. K>Где это было описано, кто-нибудь помнит?
Еще раз убеждаюсь, что вредно книжки читать
В этой фразе,конечно, есть рациональное зерно.
Но если так подходить изначально — то так и будет — все проекты будут 'файлед'
