Есть такой давно интересующий вопрос, на который я получал множество разных ответов как от проджект-менеджеров так и от обычных кодеров.
Какой должна быть скорость работы программиста и в чем ее измерять? И как определить качество работы программиста по количеству найденных в его коде ошибок бета-тестерами, его коллегами или в конце концов самими пользователями? Каков допустимый уровень "глючности" программы на разных стадиях разработки?
И как соотносятся скорость разработки программы и ее "глючности"? Каково должно быть это соотношение чтобы программист мог считаться настоящим профессионалом?
И каковы эти цифры для разных платформ, языков и технологий?
Сам я человек темный, малообразованный :) и хотелось бы получить разумный и точный ответ от многоуважаемых господ программистов.
(При ответе на вопрос условимся на том, что мы пишем не какую нибудь навороченную систему в которой множество ноу-хау и мы не делаем революцию в разработке ПО.)
А вот основные ответы по поводу скорости разработки и оценки "глючности", которые мне удалось получить:
1. Все определяется субъективно. Поставь пиво своему ПМ и коллегам и не морочь себе голову :)
2. если ты гуру ты будешь писать 2000 строк в день, занимаясь системным программированием под юникс
3. если ты простой кодер, ты обязан писать не менее 500 строк в день
4. пиши 120 строк в день и не напрягайся
5. 10-30 кб исходников "пальцами" без копи энд паст — это недельная норма
6. 10 кб кода в день "пальцами" без копи энд паст
7. 60 символов в минуту на сях :)
8. от ошибок никто не застрахован, смирись, гордыня — это грех :)
9. программирование — это очень творческая работа и измерению тут ничего не поддается, доверяй тому что тебе говорит твой ПМ и более опытные коллеги

Здравствуйте, unknown_programmer, Вы писали:

_>И каковы эти цифры для разных платформ, языков и технологий?

Кто знает...

_>А вот основные ответы по поводу скорости разработки и оценки "глючности", которые мне удалось получить:
_>1. Все определяется субъективно. Поставь пиво своему ПМ и коллегам и не морочь себе голову


Бред. ПМ самого напрягают. Он не по своей воле требует от тебя сроки.

_>2. если ты гуру ты будешь писать 2000 строк в день, занимаясь системным программированием под юникс

При чем здесь юникс? Это круто? И системное программирование? Только "сосунки" думают, что системное программирование круче прикладного... Каюсь, тоже был сосунком.

_>3. если ты простой кодер, ты обязан писать не менее 500 строк в день

Не обязан. Ни строчки.

_>4. пиши 120 строк в день и не напрягайся


А что писать? Что в этих 120-ти строках? Если нечего, то будет 0. Зато в другой день наверстаешь.

_>5. 10-30 кб исходников "пальцами" без копи энд паст — это недельная норма
_>6. 10 кб кода в день "пальцами" без копи энд паст
_>7. 60 символов в минуту на сях

Опять же бред. Смотри выше.

_>8. от ошибок никто не застрахован, смирись, гордыня — это грех


Это конечно. Но при чем здесь ошибки? Ты же объем кода оцениваешь?

_>9. программирование — это очень творческая работа и измерению тут ничего не поддается, доверяй тому что тебе говорит твой ПМ и более опытные коллеги

Здесь полностью согласен!! Именно так. Забудь про какие-то конкретные лимиты, ерунда все это... Я вот могу дня 2 вообще ничего не делать (в смысле не сделать), зато потом за полдня недельную работу замутить. Причем, работа моя продолжается и после рабочего дня — в мыслях. Бывает и ночью просыпась — еврика! Ну ты понял...

Здравствуйте, unknown_programmer, Вы писали:

в америке были проведены исследования, показавшие, что

1) Перед отдачей проекта тестерам, в нем есть 1 ошибка на 100 строк.
2) После завершения цикла тестирования, в нем есть 1 ошибка на 1000 строк.
3) 50% всех исправлений не верны.
...
список можно продолжить. (если хотите, в следующем послании, я это сделаю.)

Относится к этим данным нужно с некоторой долей скептицизма, т.к. во первых это статистика (средние данные), а во вторых скорее всего, они собраны среди американских программеров...

Здравствуйте, Lonely Dog,
Если не секрет, где вы нашли эти данные и нет ли каких нибудь книг в которых эта тема очень подробно раскрывается?
Считаете, что американские программеры хуже наших? :) или лучше?
тем более, если это исследование проводилось не раньше начала 90х, то сам термин "американские" — уже вызывает много вопросов :)

Здравствуйте, unknown_programmer, Вы писали:

_>Здравствуйте, Lonely Dog,
_>Если не секрет, где вы нашли эти данные и нет ли каких нибудь книг в которых эта тема очень подробно раскрывается?
Если честно, всю эту фигню мне читали в институте в этом году. Могу прислать лекцию в электронном варианте, где этих оценок еще больше.

_>Считаете, что американские программеры хуже наших? или лучше?
Считаю, что их средний программер хуже нашего среднего. Однако, не будем забывать , что Кнут, Ахо, Ульман, Стокмейер и пр. из америки.

_>тем более, если это исследование проводилось не раньше начала 90х, то сам термин "американские" — уже вызывает много вопросов

Че-то я не понял этого утверждения.

Здравствуйте, Demiurg,
Ваш подход конечно весьма интересен :), и он годится для ситуации, когда фирма — это 5 человек, работающих у себя на дому. Но я весьма сомневаюсь, что он применим уже для кодера работающего в команде из 20 человек. Тем более если эта команда лишь один из отделов крупной компании...

Здравствуйте, Lonely Dog, Вы писали:

LD>Здравствуйте, unknown_programmer, Вы писали:

_>>Здравствуйте, Lonely Dog,
_>>Если не секрет, где вы нашли эти данные и нет ли каких нибудь книг в которых эта тема очень подробно раскрывается?
LD>Если честно, всю эту фигню мне читали в институте в этом году. Могу прислать лекцию в электронном варианте, где этих оценок еще больше.

Вам повезло с вузом :) Кидайте на mb2000@rbcmail.ru. И желательно с библиографией. Заранее спасибо.

_>>Считаете, что американские программеры хуже наших? :) или лучше?
LD>Считаю, что их средний программер хуже нашего среднего. Однако, не будем забывать , что Кнут, Ахо, Ульман, Стокмейер и пр. из америки.

_>>тем более, если это исследование проводилось не раньше начала 90х, то сам термин "американские" — уже вызывает много вопросов :)

LD>Че-то я не понял этого утверждения. :-(

Я имел в виду многонациональный состав многих американских IT компаний.

Здравствуйте, unknown_programmer, Вы писали:

_>2. если ты гуру ты будешь писать 2000 строк в день, занимаясь системным программированием под юникс

Тутбалин колбасит 500 крейсерских строк в день и это очень хороший темп.

_>9. программирование — это очень творческая работа и измерению тут ничего не поддается, доверяй тому что тебе говорит твой ПМ и более опытные коллеги

Да нет, поддается. Только мерять надо не строчками, а другим. Например, при разработке гуйни можно мерять экранами. Пересчитал экраны у системы, поделил на, скажем, экран/неделю, имеешь трудоемкость. Если хорошоя декомпозиция, то можно считать количество функций нижнего уровня (они должны быть примерно одной трудемкости). Есть и высокая наука — функциональные точки (см.).

Ну, и, нелишне вспомнить про 30-1. Это типичный разброс производительностей программистов. Из Брукса, кажется... Брукса читал? Беги читай.

Здравствуйте, George Seryakov, Вы писали:

GS>Здравствуйте, unknown_programmer, Вы писали:

_>>2. если ты гуру ты будешь писать 2000 строк в день, занимаясь системным программированием под юникс

GS>Тутбалин колбасит 500 крейсерских строк в день и это очень хороший темп.

кто такой Тутбалин? (я же упоминал — я темный :))

_>>9. программирование — это очень творческая работа и измерению тут ничего не поддается, доверяй тому что тебе говорит твой ПМ и более опытные коллеги

GS>Да нет, поддается. Только мерять надо не строчками, а другим. Например, при разработке гуйни можно мерять экранами. Пересчитал экраны у системы, поделил на, скажем, экран/неделю, имеешь трудоемкость. Если хорошоя декомпозиция, то можно считать количество функций нижнего уровня (они должны быть примерно одной трудемкости). Есть и высокая наука — функциональные точки (см.).

логично, только вот опечатка у вас — не указали, что именно см.

GS>Ну, и, нелишне вспомнить про 30-1. Это типичный разброс производительностей программистов. Из Брукса, кажется... Брукса читал? Беги читай.

бегу :)

Здравствуйте, unknown_programmer, Вы писали:

_>кто такой Тутбалин? (я же упоминал — я темный

Тутубалин, см. Культовый программер.

GS>>... Есть и высокая наука — функциональные точки (см.).

_>логично, только вот опечатка у вас — не указали, что именно см.

Поправляюсь: см.

Здравствуйте, George Seryakov,
С Бруксом все более менее ясно. :)
Те данные о производительности, что он приводит соответствую в целом тому, что собственными глазами видел. А как вот с ошибками быть? Тут человек в этом же топике цифру привел в 1 на 100 строк и в 50% на все изменения (что тоже Бруксу соответствует).
Как скажем на практике в вашей конторе все устроено? )

Здравствуйте, unknown_programmer, Вы писали:

_>Те данные о производительности, что он приводит соответствую в целом тому, что собственными глазами видел.

Вот этого быть не должно. С его времен все несколько поменялось... кажется. По крайней мере в современном отладчике отлаживаться куда проще, чем на перфоркартах. Да еще 1-30 должно обессмысливать "данные о производительности".

_>А как вот с ошибками быть? Тут человек в этом же топике цифру привел в 1 на 100 строк и в 50% на все изменения (что тоже Бруксу соответствует).

А какой процесс? Насколько детален детальный дизайн? Ошибки, которые сделались до кодирования считаем? Это я к тому, что оно как-то не меряется. Можно прикинуть трудемкость на разработку и стабилизацию (в духе недавно помянутого MSF), но опять — все сильно зависит от процесса.

_>Как скажем на практике в вашей конторе все устроено? )

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

Здравствуйте, George Seryakov, Вы писали:

GS>Здравствуйте, unknown_programmer, Вы писали:

_>>Те данные о производительности, что он приводит соответствую в целом тому, что собственными глазами видел.

GS>Вот этого быть не должно. С его времен все несколько поменялось... кажется. По крайней мере в современном отладчике отлаживаться куда проще, чем на перфоркартах. Да еще 1-30 должно обессмысливать "данные о производительности".


там соотношение производительности разных программеров 1 к 10 указывается по числу машинных команд в программе
если сравнивать размер сырцов в КБ или строках (хотя бы из названного мне и найденного в разных источниках мною) выходят цифры менее печальные, но все равно резкий расброс есть

_>>А как вот с ошибками быть? Тут человек в этом же топике цифру привел в 1 на 100 строк и в 50% на все изменения (что тоже Бруксу соответствует).

GS>А какой процесс? Насколько детален детальный дизайн? Ошибки, которые сделались до кодирования считаем? Это я к тому, что оно как-то не меряется. Можно прикинуть трудемкость на разработку и стабилизацию (в духе недавно помянутого MSF), но опять — все сильно зависит от процесса.

все что до кодирования не в счет
играем в условиях когда сидят 10 человек с ТЗ на руках, доками и книгами под мышкой и вопрос стоит "кто здесь лучше? кому я могу доверить самый ответственный и "вкусный" кусок проекта? кто лучше и быстрее все это закодирует??"

_>>Как скажем на практике в вашей конторе все устроено? )

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

как все грустно :(

Здравствуйте, George Seryakov,
и как вы относитесь к данным статистики упомянутым у того же Брукса, в которых говорится, что производительность практически не зависит от опыта?
Я с ними согласен в случае чистого кодерства, но чем больше отход от чистого кодерства в сторону постановки тем больше становиться зависимость от опыта.

Работал ли кто нибудь из присутствующих на форуме в российских программерских конторах имеющих сертификат на собственную систему контроля качества соответствующую ISO 9000?
Я так понимаю стандарт определяет лишь общие положения этого вопроса, а в каждой конторе стандарт реализован по своему.
Можно ли где нибудь найти какую либо документацию на конкретную реализацию этого стандарта? (реализацию не для галочки, а используемую в деле) Или все эти вещи — комм. тайна и хранятся за семью печатями?

Здравствуйте, George Seryakov, Вы писали:

_>>логично, только вот опечатка у вас — не указали, что именно см.

GS>Поправляюсь: см.

Ты только зря по русски искал, почти ничего не находится.

см http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm

Здравствуйте, unknown_programmer, Вы писали:

GS>>А какой процесс? Насколько детален детальный дизайн? Ошибки, которые сделались до кодирования считаем? Это я к тому, что оно как-то не меряется. Можно прикинуть трудемкость на разработку и стабилизацию (в духе недавно помянутого MSF), но опять — все сильно зависит от процесса.

_>все что до кодирования не в счет
_>играем в условиях когда сидят 10 человек с ТЗ на руках, доками и книгами под мышкой и вопрос стоит "кто здесь лучше? кому я могу доверить самый ответственный и "вкусный" кусок проекта? кто лучше и быстрее все это закодирует??"

Истина конкретна. А "быстрее" и "лучше" совместимы не всегда. Ответственный кусок будет дан тому, кто свободен и кто не наколбасит в ядре.

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

_>как все грустно

Ты впечатлителен. Я мог бы рассказать все то же самое в терминах MSF, и ты тогда сказал бы "как здорово!".

На самом деле все имееь свои причины. UPS, где я работаю, это супермонстр, он существует уще 80 лет, его бизнес-процессы развиваются все 80 лет и посейчас содержат в себе инноваци 80-летней давности. Нужно ли говорить, что они не документированы и существуют только в умах владельцев знания. Узнать, что нужно реализовать можно только начав реализовывать. По научному это еще как-то называется, лень вспоминать.

Здравствуйте, unknown_programmer, Вы писали:

_>Здравствуйте, George Seryakov,
_>и как вы относитесь к данным статистики упомянутым у того же Брукса, в которых говорится, что производительность практически не зависит от опыта?

Я это называю вменяемостью. Либо есть она либо нет.

_>Я с ними согласен в случае чистого кодерства, но чем больше отход от чистого кодерства в сторону постановки тем больше становиться зависимость от опыта.

От знания предметной области, умения разбираться в предметных областях. Но прежде этого — от вменяемости.

И, я бы вообще не говорил о производительности. Я бы говорил просто о способности программировать. Эдак, бинарно. Починит или наколбасит, прибирать за ним придется.

Здравствуйте, unknown_programmer, Вы писали:

_>Работал ли кто нибудь из присутствующих на форуме в российских программерских конторах имеющих сертификат на собственную систему контроля качества соответствующую ISO 9000?

Я работал на аргуссофт, впоследствии сертифицированнй на 9000-3. Поверь мне, мистический ужас испытывать не перед чем. Среди банковских автоматизаторов ходит такое выражение (приписываемое, кажется, Калянову) "Автоматизация бардака дает автоматизированный бардак". С сертификацией... нет, я могу, точнее, не могу говорить про единсвенный пример.

_>Я так понимаю стандарт определяет лишь общие положения этого вопроса, а в каждой конторе стандарт реализован по своему.

Так.

_>Можно ли где нибудь найти какую либо документацию на конкретную реализацию этого стандарта? (реализацию не для галочки, а используемую в деле) Или все эти вещи — комм. тайна и хранятся за семью печатями?

Тайна. ДСП. У меня была копия. Может быть, и сейчас есть, если мой комп в Москве не переформатировали. Ничего особенного, обычная советская туфта. Пишется задней ногой. Я счастлив, что в Америке этим не занимаюсь.

Здравствуйте, Anatolix, Вы писали:

GS>>Поправляюсь: см.

A>Ты только зря по русски искал, почти ничего не находится.

Хотел приучить клиента искать.

A>см http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm

В комплекте к SE Compagnion, кажется, был официальный рулез от FPGroup в виде виндового хелпа. Его и следует искать.

Здравствуйте, George Seryakov, Вы писали:

GS>Тайна. ДСП. У меня была копия. Может быть, и сейчас есть, если мой комп в Москве не переформатировали. Ничего особенного, обычная советская туфта. Пишется задней ногой. Я счастлив, что в Америке этим не занимаюсь.

я так понимаю вы сейчас в штатах?
а как на западе обстоит с этим делом? (то есть с моим вопросом)
ваша контора не в счет — вы уже упоминали

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, George Seryakov, Вы писали:

_>>>логично, только вот опечатка у вас — не указали, что именно см.

GS>>Поправляюсь: см.

A>Ты только зря по русски искал, почти ничего не находится.

A>см http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm

конкретную методику подсчета еще не посмотрел, но вроде это и есть оно самое :)
интуитивно предполагал, что что-то в этом роде должно быть, но не думал, что уже наука такая есть

Здравствуйте, unknown_programmer, Вы писали:

_>я так понимаю вы сейчас в штатах?
_>а как на западе обстоит с этим делом? (то есть с моим вопросом)

Точно так же (про количество и качество). С той некоторой поправкой, что тут на программистов учат, что не может не сказаться понижением уровня. Русские-то все больше самоучки.

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

Здравствуйте, George Seryakov, Вы писали:

GS>Тайна. ДСП. У меня была копия. Может быть, и сейчас есть, если мой комп в Москве не переформатировали. Ничего особенного, обычная советская туфта. Пишется задней ногой. Я счастлив, что в Америке этим не занимаюсь.

тайна так тайна )
просто интересно можно ли в каких либо реализациях стандарта найти ответ на мой вопрос?

Здравствуйте, unknown_programmer, Вы писали:

GS>>Тайна. ДСП. У меня была копия. Может быть, и сейчас есть, если мой комп в Москве не переформатировали. Ничего особенного, обычная советская туфта. Пишется задней ногой. Я счастлив, что в Америке этим не занимаюсь.

_>просто интересно можно ли в каких либо реализациях стандарта найти ответ на мой вопрос?

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

2 George Seryakov:
у меня вопрос несколько не в тему
вы в своей инфе указали, что ваша специализация VC++/COM/ATL/MTS, Automation
мне в процессе своего относительно небольшого опыта работы никогда не приходилось работать рядом с программерами со стажем и опытом намного превосходящим мой (да еще и с физтеховским образованием), обычно сверстники, новички или вообще левые к программированию люди — дизайнеры или системные инженеры
и вопрос у меня такой — какой уровень теоретических знаний необходим программисту претендующему на профессионализм, высокую зарплату итп итд?
программирование и кодирование без постоянного обращения к документации в вашей (и частично моей) специализации — это бред и невыполнимое требование — или практика?
ситуация, при которой я пишу все что угодно (и в 2 раза минимум быстрее большинства, хотя возможно несколько небрежно, трудно сказать — если доверять тем цифрам что мне говорят знакомые и в разных форумах — объем кода на единицу времени в одинаковых условиях), но не считаю нужным держать в памяти кучу вещей — это нормально?
или для нормальной работы в какой нибудь серьезной московской (я не из столицы) фирме — необязательно большой, но с серьезным а не дилетантским подходом к программированию — мне необходимо сосредоточиться на узкой области и постоянно тренируясь просто держать в памяти скажем только вещи перечисленные выше (VC++/COM/ATL/MTS, Automation — просто для примера)?
просто мне, как я уже сказал, сам опыт работы такой информации не дал

Здравствуйте, unknown_programmer, Вы писали:

_>и вопрос у меня такой — какой уровень теоретических знаний необходим программисту претендующему на профессионализм, высокую зарплату итп итд?

Это неважно. Важно — уметь get things done. То есть уметь решать проблемы. Уметь понять проблему, найти способ решения, реализовать его. И сделать все это так, чтоб не создавать других проблем.

_>программирование и кодирование без постоянного обращения к документации в вашей (и частично моей) специализации — это бред и невыполнимое требование — или практика?

Не знаю. Я часто лезу в MSDN, но часто и затем, чтобы показать другим, что они не прочитали. Но также и могу себе представить некую сессию, во время которой в доку не лазил. При наличии хорошей спецификации требований лазить в нее постоянно — нужно.

_>ситуация, при которой я пишу все что угодно (и в 2 раза минимум быстрее большинства, хотя возможно несколько небрежно, трудно сказать — если доверять тем цифрам что мне говорят знакомые и в разных форумах — объем кода на единицу времени в одинаковых условиях), но не считаю нужным держать в памяти кучу вещей — это нормально?

Твоя память — тебе и решать, что там держать. Тут все нормально. Но если ты много работал с технологией X, то некоторые вещи ты — хочешь-не хочещь — оттуда запомнишь. Этим часто пользуются при проверке опыта.

Здравствуйте, George Seryakov,

сэнкс )

Здравствуйте, unknown_programmer, Вы писали:

_>Работал ли кто нибудь из присутствующих на форуме в российских программерских конторах имеющих сертификат на собственную систему контроля качества соответствующую ISO 9000?
_>Я так понимаю стандарт определяет лишь общие положения этого вопроса, а в каждой конторе стандарт реализован по своему.
_>Можно ли где нибудь найти какую либо документацию на конкретную реализацию этого стандарта? (реализацию не для галочки, а используемую в деле) Или все эти вещи — комм. тайна и хранятся за семью печатями?

Я работал на контору, которая имеет SW CMM Level 3.
Поскольку CMM разрабатывался именно для оценки софтварных контор,
то толку от него будет поболе. Ну не верю я что один и тот же стандарт
успешно применим для кондитерской фабрики и для софтварной конторы.
Т.е. ISO 9000 конечно показывает, что в конторе есть минимальный уровень необходимой бюрократии,
но качественной оценки он не дает.
Так вот, у нас все нормативные документы для CMM имеют гриф ДСП.
Но на самом деле даже если вы этот пакет поимеете, он вам не сильно поможет жить.
Смысл подготовки на уровень CMM — пройти через все мучения и трудности самому.
Только если компания сама для себя осознала необходимость работы над этим
и делает добровольно и осознанно, только тогда будет толк.
А так в интернете можно найти довольно много примеров нормативных документов
контор, которые имеют CMM Level 5. Мне, например, попадалось кое-что от Боинга.

P.S.
Есть другой стандарт ISO, который применим именно для софтварных контор.
Номер стандарта не помню, но ноги у него ростут из http://www.sqi.gu.edu.au/spice/

Здравствуйте, unknown_programmer, Вы писали:

_>Ваш подход конечно весьма интересен , и он годится для ситуации, когда фирма — это 5 человек, работающих у себя на дому.

Почему именно на дому?


_> Но я весьма сомневаюсь, что он применим уже для кодера работающего в команде из 20 человек. Тем более если эта команда лишь один из отделов крупной компании...


Не знаю, может и неприменим. Но я представить себе не могу, чтоб я каждый день выдавал на гора 500 строк кода. То есть выдать-то я могу, но не придется ли потом все это убить нахрен?

Здравствуйте, Demiurg, Вы писали:

D>Здравствуйте, unknown_programmer, Вы писали:

_>>Ваш подход конечно весьма интересен :), и он годится для ситуации, когда фирма — это 5 человек, работающих у себя на дому.

D> Почему именно на дому? :)


_>> Но я весьма сомневаюсь, что он применим уже для кодера работающего в команде из 20 человек. Тем более если эта команда лишь один из отделов крупной компании...


D> Не знаю, может и неприменим. Но я представить себе не могу, чтоб я каждый день выдавал на гора 500 строк кода. То есть выдать-то я могу, но не придется ли потом все это убить нахрен?

от вас самих зависит :)
подумайте прежде чем выдавать
чем быстрее думаете и больше знаете, тем больше и выдадите

Здравствуйте, Demiurg, Вы писали:

D> Не знаю, может и неприменим. Но я представить себе не могу, чтоб я каждый день выдавал на гора 500 строк кода. То есть выдать-то я могу, но не придется ли потом все это убить нахрен?

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

Здравствуйте, unknown_programmer, Вы писали:

D>> Не знаю, может и неприменим. Но я представить себе не могу, чтоб я каждый день выдавал на гора 500 строк кода. То есть выдать-то я могу, но не придется ли потом все это убить нахрен?

_>от вас самих зависит
_>подумайте прежде чем выдавать
_>чем быстрее думаете и больше знаете, тем больше и выдадите

То что нужно — думать — это понятно. Но ведь бывает такое, когда не думается... Или не хочется Вот и сидишь почту читаешь, решение потом само в голове всплывает. Это мне напоминает как если бы с художника требовали в день не меньше ведра краски использовать

Здравствуйте, unknown_programmer, Вы писали:

_>нет ли каких нибудь книг в которых эта тема очень подробно раскрывается?
Тестирование программного обеспечения

Автор(ы): Сэм Канер, Джек Фолк, Енг Кек Нгуен

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

Канер и компания.

Здравствуйте, unknown_programmer, Вы писали:

_>Какой должна быть скорость работы программиста и в чем ее измерять? И как определить качество работы программиста по количеству найденных в его коде ошибок бета-тестерами, его коллегами или в конце концов самими пользователями? Каков допустимый уровень "глючности" программы на разных стадиях разработки?
В среднем за день работы набирается 5 — 10 строк готового кода. Это я на Delphi так работаю.
На MASM получается строк 100 — 300.

Глючнось — зависит от допусков.
Я привёл цифры для готового , год-два отработавшего кода.