Срачь на тему "почему метакласс думает за заказчиков и решает простые задачи сложным образом": eleon "как ПМ знаю, что лучше 5 раз быстро, чем 1 раз правильно".
Вы еще удивляетесь, почему в IT в большинстве случаев творится оверпрайсед вред?
Есть большая разница между: а) понимая, как сделать быстро и как с другой стороны сделать правильно, осознавая последствия в каждом из этих случаев, осознанно выбрать компромисс в ту или другую сторону б) ни фига не понимая, как сделать правильно и как сделать быстро, сделать как-нибудь в) всегда настаивать на "правильном" (с точки зрения тараканов в голове) решении, долго разрабатывать и получить в итоге нафиг никому не нужное за такие деньги и к такому сроку решение
Вариант а) правильный вне зависимости от того, в какую сторону был выбран компромисс.
Это уже не говоря о том, что правильность - критерий не просто субъективный, а еще и относительный. При разработке софта для управления авионикой в самолете правильно бывает использовать ИСО-9000, писать заранее тонны документации и тестов, практиковать парную разработку и код ревью и т.п. В то же время при разработке развлекательной софтинки для iPhone важно первым занять рынок с "good enough" продуктом. А переписать его по правильному можно будет и потом, если взлетит.
no subject
Date: 2012-11-22 02:26 pm (UTC)а) понимая, как сделать быстро и как с другой стороны сделать правильно, осознавая последствия в каждом из этих случаев, осознанно выбрать компромисс в ту или другую сторону
б) ни фига не понимая, как сделать правильно и как сделать быстро, сделать как-нибудь
в) всегда настаивать на "правильном" (с точки зрения тараканов в голове) решении, долго разрабатывать и получить в итоге нафиг никому не нужное за такие деньги и к такому сроку решение
Вариант а) правильный вне зависимости от того, в какую сторону был выбран компромисс.
Это уже не говоря о том, что правильность - критерий не просто субъективный, а еще и относительный. При разработке софта для управления авионикой в самолете правильно бывает использовать ИСО-9000, писать заранее тонны документации и тестов, практиковать парную разработку и код ревью и т.п. В то же время при разработке развлекательной софтинки для iPhone важно первым занять рынок с "good enough" продуктом. А переписать его по правильному можно будет и потом, если взлетит.