Архив Е.В.

[ALEXandr]

Net, ne zapustili.
Ushe 10-y programmist ne sposoben ni modernizirovat' dvijok Buly4eva, ni sdelat' novyj kloniruemyj hotja by polovinnoj funkcionalnosti.
Dumaju, tut delo ne prosto v neverojatnoj tuposti nyneschnego pokolenija programmistov. Esli voznikajut takie prepjatstvija na protjajenii 2h let, zna4it - Gospod' ne ho4et, 4toby byli novye saity. I huj s nim: hvatit suschestvujuschih

Честно говоря не верю что так уж сложно разобраться с движком.
Может им мало платите?

Или они просто считают что денег у вас должно быть не меряно, и целенаправленно затягивают процесс, в надежде нагреться. А у вас не хватает терпения и посылаете их на куй.

Обратная сторона популярности.

[Колобок]

Ерунда, это значит всего лишь то, что код Булычёва трудно читаем. Надо писать с нуля по новой.

[avl]

У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит?

[vvk]

У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит?

Может господь хочет, чтобы программисты перешли на декларативные языки и среды программирования?

[Колобок]

У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит?

Может господь хочет, чтобы программисты перешли на декларативные языки и среды программирования?

Господь хочет, чтобы он перестал заниматься программированием и занялся чем-то, к чему лежит душа и способности

[Flammar]

У меня вот тоже даже простешие программы с трудом идут, хотя я профессиональный программист. Может господь и вправду к программам не очень благоволит?

Может господь хочет, чтобы программисты перешли на декларативные языки и среды программирования?

Господь хочет, чтобы он перестал заниматься программированием и занялся чем-то, к чему лежит душа и способности

Терроризмом или другим криминалом, например...

[t_vitali]

Вообще народ - кто нибудь в скриптах пробовал разбираться? Особенно если скрипты  писал гений одиночка? Млин...
Если код писался не соблюдая стандартов, тем более скрипты, то обычно легче старый код на хер выбросить и новый написать. Это давно известная проблема и она решаема - по пальцам железной линейкой. Для того что бы таких косяков не было - пишут группами, + обязательное ведение документации, + постоянные код ревью и ещё много всякой всячины (такой как планы развития с описанием фичеров, Source Safe - чтобы можно было бы отслеживать изменения, вести версии, тестирование и т.д.). Это уже технология господа - Software Development называется. То есть должны быть организованны процессы в рамках проекта. А когда всё отдаётся на откуп одному человеку, тем более гению, когда он исчезает - проект рушится. ШЭЛ не первый кто на эти грабли наступил.
ШЭЛ сам по себе проект большой. Когда то можно было что то на коленке нацарапать и это работало. Но вот с изменениями и расширением проблемы. Это результат отсуцтвия менеджмента и просто технологии.
Моя мысль такая - не зачем свой не профессионализм и отсутствие опыта списывать на Господа. Он лишь указывает - ШЕЛ проэкт большой и серьёзный. Поэтому требует серьёзного к себе отношения. Господь говорит - измени отношение и сделай шаг вперёд. Перестань ШЭЛ воспринимать легко.
Нужна команда которая будет проект развивать или поддерживать. Нужен менеджер. Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией. Потом пусть админ - администрирует, а контора дописывает фичеры.

[Flammar]

Вообще народ - кто нибудь в скриптах пробовал разбираться? Особенно если скрипты  писал гений одиночка? Млин...
Если код писался не соблюдая стандартов, тем более скрипты, то обычно легче старый код на хер выбросить и новый написать. Это давно известная проблема и она решаема - по пальцам железной линейкой. Для того что бы таких косяков не было - пишут группами, + обязательное ведение документации, + постоянные код ревью и ещё много всякой всячины (такой как планы развития с описанием фичеров, Source Safe - чтобы можно было бы отслеживать изменения, вести версии, тестирование и т.д.). Это уже технология господа - Software Development называется. То есть должны быть организованны процессы в рамках проекта. А когда всё отдаётся на откуп одному человеку, тем более гению, когда он исчезает - проект рушится. ШЭЛ не первый кто на эти грабли наступил.
ШЭЛ сам по себе проект большой. Когда то можно было что то на коленке нацарапать и это работало. Но вот с изменениями и расширением проблемы. Это результат отсуцтвия менеджмента и просто технологии.
Моя мысль такая - не зачем свой не профессионализм и отсутствие опыта списывать на Господа. Он лишь указывает - ШЕЛ проэкт большой и серьёзный. Поэтому требует серьёзного к себе отношения. Господь говорит - измени отношение и сделай шаг вперёд. Перестань ШЭЛ воспринимать легко.
Нужна команда которая будет проект развивать или поддерживать. Нужен менеджер. Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией. Потом пусть админ - администрирует, а контора дописывает фичеры.

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

[AlexD]

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).

[Father]

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).

А чем плохо купить готовый движок? Вроде их куча.

[Flammar]

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).

Тогда еще и контролера нанимать...

[druidm]

Повешайте ТЗ
и кто может или хочет или кого-то может посоветовать, Вам напишет
сколько нужно времени и денег, чтобы сделать(купить, установить) софтину для проекта ШЭЛ

[Ramil]

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).

Как говорил мой бывший шеф: Цену проекта очень легко определить. Смотришь сколько стоит автомобиль ген. директора.  Ровно столько стоит система автоматизации его фирмы.
Так, на чем ездит Евгений Витальевич ?

[Евгений_Витальевич]

Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.

Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.

[Евгений_Витальевич]

Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.

Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.

Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.

[Евгений_Витальевич]

Так, на чем ездит Евгений Витальевич ?

BMV m3 turbo evclusiv

[t_vitali]

Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.

Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.

Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.

Я вижу что рынок для консалтинга большой.
Контора на которую я работаю продаёт программы в часности инвест банкам. И пишем группами по 7 - 12 человек. QA отдельная группа. Один человек работу в моём последнем проекте лет за 15 только смог бы сделать. Всё таки за последние 15 лет технология и методология написания программ продвинулась вперёд. Документацию для юзеров пишут специальные люди - у нас целый отдел. Девелоперы пишут техническую документацию, менеджеры собирают юзер реквайрментс, пишут планы, разрабтывают work brakedown structure and ect. Если девелопер не пишет положенные документы то это значит процессы разработки софта не поствлены или их вообще нет. А если он принципиально их не пишет то это значит он или не соотвецтвует заимаемой должности или использует технику secure your workplace и в обоих случаях от него нахер избавляться надо быстрее.
420 фирм - это большая выборка. Как поделился опытом работы с русской компанией мой друг (то же менеджер) - их надо держать на голодном пайке и деньги платить когда уже проект закончен. Можно сказать одно - работать не умеют ни хуя. Сказывается отсуцтвие опыта и толковых менеджеров.
 

[t_vitali]

Вообще народ - кто нибудь в скриптах пробовал разбираться? Особенно если скрипты  писал гений одиночка? Млин...
Если код писался не соблюдая стандартов, тем более скрипты, то обычно легче старый код на хер выбросить и новый написать. Это давно известная проблема и она решаема - по пальцам железной линейкой. Для того что бы таких косяков не было - пишут группами, + обязательное ведение документации, + постоянные код ревью и ещё много всякой всячины (такой как планы развития с описанием фичеров, Source Safe - чтобы можно было бы отслеживать изменения, вести версии, тестирование и т.д.). Это уже технология господа - Software Development называется. То есть должны быть организованны процессы в рамках проекта. А когда всё отдаётся на откуп одному человеку, тем более гению, когда он исчезает - проект рушится. ШЭЛ не первый кто на эти грабли наступил.
ШЭЛ сам по себе проект большой. Когда то можно было что то на коленке нацарапать и это работало. Но вот с изменениями и расширением проблемы. Это результат отсуцтвия менеджмента и просто технологии.
Моя мысль такая - не зачем свой не профессионализм и отсутствие опыта списывать на Господа. Он лишь указывает - ШЕЛ проэкт большой и серьёзный. Поэтому требует серьёзного к себе отношения. Господь говорит - измени отношение и сделай шаг вперёд. Перестань ШЭЛ воспринимать легко.
Нужна команда которая будет проект развивать или поддерживать. Нужен менеджер. Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией. Потом пусть админ - администрирует, а контора дописывает фичеры.

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

Вопрос тут не не в деньгах. Вероятность того что они будут проёбаны = 98%. При чем если индусы делают всё красиво - и документы, и код дукументирован и аботает иногда - то тут получешь на выходе только отмазки.
Процессы должны быть поставлены. Выяснено, чего же заказчик на самом деле хочет, разработанны планы, просчитанно - а сколько это будет стоить? Потом принимается решение - делать или нет. При этом фаза исследования может достигать стоимости до 5% от стоимости проекта.

[t_vitali]

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).

Как говорил мой бывший шеф: Цену проекта очень легко определить. Смотришь сколько стоит автомобиль ген. директора.  Ровно столько стоит система автоматизации его фирмы.
Так, на чем ездит Евгений Витальевич ?

М-да.... Вот Вам и методология. Млин....

[Flammar]

Чем критиковать, лучше денег дай . Сколько там надо на такую нормальную работу - 5 месяцев * 5 человек * 1,5 штуки в месяц каждому = 40 штук на новый движок (с гарантией 50%)?

От требований зависит. Но исходя из моего опыта:
3 месяца (max) * 2 человека (max) * как договоришься (вилка думаю от 500 - 1500) = 3000 - 9000 (с вероятностью 90%, если нормально контролировать процесс, а не забить на него и только спрасить результат спустя 3 месяца).

Как говорил мой бывший шеф: Цену проекта очень легко определить. Смотришь сколько стоит автомобиль ген. директора.  Ровно столько стоит система автоматизации его фирмы.
Так, на чем ездит Евгений Витальевич ?

М-да.... Вот Вам и методология. Млин....

Это стоимость системы автоматизации бардака Который по определению невозможно автоматизировать.

[Flammar]

Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.

Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.

Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.

Я вижу что рынок для консалтинга большой.
Контора на которую я работаю продаёт программы в часности инвест банкам. И пишем группами по 7 - 12 человек. QA отдельная группа. Один человек работу в моём последнем проекте лет за 15 только смог бы сделать. Всё таки за последние 15 лет технология и методология написания программ продвинулась вперёд. Документацию для юзеров пишут специальные люди - у нас целый отдел. Девелоперы пишут техническую документацию, менеджеры собирают юзер реквайрментс, пишут планы, разрабтывают work brakedown structure and ect. Если девелопер не пишет положенные документы то это значит процессы разработки софта не поствлены или их вообще нет. А если он принципиально их не пишет то это значит он или не соотвецтвует заимаемой должности или использует технику secure your workplace и в обоих случаях от него нахер избавляться надо быстрее.
420 фирм - это большая выборка. Как поделился опытом работы с русской компанией мой друг (то же менеджер) - их надо держать на голодном пайке и деньги платить когда уже проект закончен. Можно сказать одно - работать не умеют ни хуя. Сказывается отсуцтвие опыта и толковых менеджеров.

Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.

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

[Колобок]

Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.

Одно дело стандарты, другое дело читабельность кода. Стандарты во всех фирмах разные. А легко читаемый код можно писать и без стандартов. Пожалуй, это одна из основных характеристик хорошего программиста, по моему мнению. Как говорит знакомый руководитель проектов, хорошая программа сама по себе и является документацией.

[grigory]

Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.

Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.

Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.

[/QUOTE]


Евгений Витальевич!

После того, как Вы точно поймете, стоит ли доводить этот проект до его запланированного ранее развития, предлагаю выложить ТЗ (или разослать его по запросу всем желающим) и выбрать после этого самую достойную команду из всех, предложивших свои услуги.

Думаю, что многие выпускники ШЭЛ, да и члены этого форума, готовы оказать помощь Проекту в поиске достойных программистов.

[t_vitali]

Идеальный вариант нанять фирму, что бы систему управления контентом написали по уму и с документацией.

Probovali i eto. V rezultate polu4ili produkt raz v 10 huje nyneshnego.

Tut komandu sdelat' ushe pytalis' - dlja razrabotki tehzadanija. Rezultat=govno.
Napisat' 4to0to rabotajuschee sposoben tolko 1 4elovek. No dokumentacii vse ravno ne dojdeschsja

Vse firmy starajutsja za 10000 prodat' svoi starye razrabotki. Ilja byl edinstvennym za 5 let, kto vse sdelal s nulja po moemu TZ.   Ostal'nye 420 individualnyh razrabot4ikov i firm, s kotorymi ja imel delo za 5 let, okazyvalis' moshennikami ili bezdarjami, ne sposobnymi k 4emu-tu priemlemomu.
Den'gi roli tut ne igrajut.

Я вижу что рынок для консалтинга большой.
Контора на которую я работаю продаёт программы в часности инвест банкам. И пишем группами по 7 - 12 человек. QA отдельная группа. Один человек работу в моём последнем проекте лет за 15 только смог бы сделать. Всё таки за последние 15 лет технология и методология написания программ продвинулась вперёд. Документацию для юзеров пишут специальные люди - у нас целый отдел. Девелоперы пишут техническую документацию, менеджеры собирают юзер реквайрментс, пишут планы, разрабтывают work brakedown structure and ect. Если девелопер не пишет положенные документы то это значит процессы разработки софта не поствлены или их вообще нет. А если он принципиально их не пишет то это значит он или не соотвецтвует заимаемой должности или использует технику secure your workplace и в обоих случаях от него нахер избавляться надо быстрее.
420 фирм - это большая выборка. Как поделился опытом работы с русской компанией мой друг (то же менеджер) - их надо держать на голодном пайке и деньги платить когда уже проект закончен. Можно сказать одно - работать не умеют ни хуя. Сказывается отсуцтвие опыта и толковых менеджеров.

Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.

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

Со всем уважением - это немного устаревшие представления. Вся современная технология написания програм как раз и избегает создания голема. Группы собираются из 6 - максимум 12 человек (если 12 человек то уже работаю с групп лидерами). Вот для этого и нужен менеджер. Видимо тут присуцтвует понимание стандарта как на конвейре - отступ 2 миллиметра и не более. При понимании стандартов как некоторых правил которые облегчают работу всех в группе ( и в компании )  на выходе имеем совершенно другое. К стати и стандарты группа принимает в начале проекта сама. Если что то не устраивает то либо стандарт меняется, либо если, что то что зависит от компании целиком - Source Safe, или Rationl Rose Uninfied Process используется к примеру то курсы организуются и т.д.
Конечно писать документы очень тяжело. Документы для юзеров ишут не девелоперы, а переводчики с технического на нормальный язык Technical Writers. Но документы необходимые в проессе разработки (Functional Requirement Specification, High level design description, Class Diagramm) пишутся девелоперами. Это уже часть квалификации - без этого это не  девелопер - это код манки. На работу не возьмут.

Проблема одиночки гения vs работы группы. Во первых компании которые превращают деелопмент групы в големы блюдущие стандарты долго не живут - не конвейер. Но всё же современный Software Development - это результат работы группы. Посмотри на это немного с другой стороны. Сравни - сколько может написать один гений и сколько может написать группа из 5 - 10 человек? Несравнимо. Гений будет писать 2 года  то что группа сделает за 6 месяцев. А полтора года на рынке это очень много. Потом - написание программы это только часть процесса. Потом её надо передать клиенту, фиксить баги, вносить изменения - у клиента ведь обстоятельства и желния меняются. Как это делать? Ведь нормальному человеку хочется новое писать, а не ковыряться с багами, или менять то что написанно. А гений уйдёт просто с работы. А если он башку кому нибудь проломит? Всё? Фирма влетела и разорилась? Риски то просчитываются. Вот посмотри на ситуацию - пропал разработчик и всё - проект встал в развитии.
Я стобой согласен - гений и работает быстрее и эффективней и код красивее. Но вот заболел он и проек слился в говно. А если работать с клиентами с которыми моя теперешняя контора работает то и вся фирма. Подымись на одну ступень выше. Посмотри на процесс с точки зрения проекта.
Тут интересно сравнить мой опыт работы в Израиле и в Канаде. В Израиле программеры на две головы в среднем выше чем в Канаде. Таких групп лидеров которе были у меня таких тут просто нет. Золоте головы. А менеджмент намного слабее. В Канаде наоборот - программеры слабые, а менеджмент очень сильный. В реультате делают в два раза больше и качественней. Только за счет организации. И работают только положенные 9 часов. В Израиле были сплошные овертаймы.

[t_vitali]

Эффективно можно заниматься одним из двух - либо писать код либо блюсти стандарты. Из тех, кто эффективно блюдет стандарты, можно, как из деталей, собирать некий голем. Из тех, кто эффективно пишет - намного труднее. Я еще где-то в 1997 заметил, что написание документации на программу - дело более трудоемкое, чем написание самой программы.

Одно дело стандарты, другое дело читабельность кода. Стандарты во всех фирмах разные. А легко читаемый код можно писать и без стандартов. Пожалуй, это одна из основных характеристик хорошего программиста, по моему мнению. Как говорит знакомый руководитель проектов, хорошая программа сама по себе и является документацией.

Читабельность кода - это часть стандарта, да и просто правило хорошего тона. Второе утверждение - о хорошей программе - довольно распостранённое заблуждение. Тех кто может это действительно сделать по пальцам пересчитать - остльные только считают, что они крутые.
Хорошая организация процесса позволяет с посредственными программерами делать больше и лучше, позволяет скомпенсироватьих недостатки. Что в общем и делают на западе в общем. Посмотришь - ну бараны вокруг работают, а идут в одном направлении, стены проламывают, результатов добиваются блестящх и при этом не сильно напрягаются.