К вашей схеме могу пару своих копеек: для качественного выполнения частей проекта при условии достаточных ресурсов (все же Корпорация!) можно дублировать одни и те же задачи на несколько исполнителей и выбирать лучший вариант или лепить из нескольких. Конкурс своеобразный.
Вот простой пример: сделать формочку с такими-то контрольчиками. Все описано, подробно, с картинками. Сделали. Смотрим — а там TabOrder по всей форме гуляет.
Вроде как сам должен программер должен понимать такие вещи — а он круглые глаза делает и говорит «я вообще с клавы не проверял», мышкой потыкал, и вообще об этом в ТЗ ни слова.
Год назад меня знакомые приглашали в Газпром разрабатывать новый проект с нуля. Очень интересная работа, да и вознаграждение у Газпрома неплохое (кстати не заоблачная з/п) + социалка. Отказался. А знаете почему? Потому что рабочий день с 8 до 8.
В перспективе, офисное рабство сменится таким же рабством дома за собственным компьютером и еще неизвестно что лучше.
Тем не менее поддерживаю ваши идеи, просто такая схема работы не масштабируется на любую IT-деятельность и любых исполнителей.
К примеру, у нас в компании несколько человек заняты разработкой под мобильные терминалы сбора данных. При стоимости среднего терминала в 40-50 тыр на столе такого разработчика может лежать по полляма денег. Никто не даст им такую работу домой.
это не Scale on Demand а скорее Refactoring on Demand
Тем не менее такая схема на мой взгляд единственно верная для стартапов, сильно ограниченных в ресурсах.
Лучше потратить ресурсы на продвижение, чем сделать идеальный с технической точки зрения продукт, которым никто не пользуется. Ведь полпулярность продукта мало зависит от «нормальности» его БД, согласны?
да, и мало-мальски сложный продукт по-любому будет прибит гвоздями к реализации SQL, хотя бы в силу отсутствия внятных стандартов на синтаксис хранимых процедур.
Я к тому, что вопрос качества не решается подробным ТЗ. Но решается репутацией и личными связями.
Вроде как сам должен программер должен понимать такие вещи — а он круглые глаза делает и говорит «я вообще с клавы не проверял», мышкой потыкал, и вообще об этом в ТЗ ни слова.
Железки нужны чтобы отлаживать на них программы. На эмуляторах такой специфический софт не отладить.
Тем не менее поддерживаю ваши идеи, просто такая схема работы не масштабируется на любую IT-деятельность и любых исполнителей.
К примеру, у нас в компании несколько человек заняты разработкой под мобильные терминалы сбора данных. При стоимости среднего терминала в 40-50 тыр на столе такого разработчика может лежать по полляма денег. Никто не даст им такую работу домой.
Тем не менее такая схема на мой взгляд единственно верная для стартапов, сильно ограниченных в ресурсах.
Лучше потратить ресурсы на продвижение, чем сделать идеальный с технической точки зрения продукт, которым никто не пользуется. Ведь полпулярность продукта мало зависит от «нормальности» его БД, согласны?
Кстати у меня закрались сомнения что TOP описан в стандарте SQL99. Пруфом не поделитесь?
и вы еще призываете не использовать «странные и сомнительные СУБД»
SQLite вообще ничего не умеет, его область применения очень ограничена.