Здравствуйте, Gaperton, Вы писали:
T>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>Не определил по одной простой причине — её не существует. G>По одной простой причине — ты не настолько хорошо понимаешь проблему, чтобы определить количественную меру.
100% не настолько хорошо. Хорошо если хотя бы на 0.5%.
IT>>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. G>Техника работы с метриками основана на измерениях, сравнениях, анализе истории и поиске статистических закономерностей, а не "универсальных формулах для любого программиста".
К сожалению, метрики никак не помогают мне при принятии решений, которые я как программист принимаю десятками ежедневно. А из этих решений в конце концов складывается результат, который может быть потом и можно как-то померить.
G>Последнее — глупость.
Глупость — не только последнее, а вообще любое использование метрик.
G>Для твоего случая — время на объем, плюс процентная раскладка времени на каждый этап. Вводи по очереди разные факторы, и проведи статистическое исследование, если тебе интересно. Мне предложенное тобой сравнение кажется лишенным какой-ли практической пользы. Так, абстрактное умствование.
Статистическое исследование подразумевает как минимум необходимость понаблюдать за процессом. Т.е. мы получим какие-то данные после того как уже будет поздно пить боржоми. Какой мне толк от знания того, что на решение задачи X с помощью технологии Y было затрачено Z Васе-Коле-Вите-часов, если в следующий раз я буду решать задачу A, используя технологию B и привлеку для её решения Петю и Ваню?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
IT>>А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях? I>С Васями и Колями хорошо, когда у тебя есть один Вася и один Коля и ты интуитивно представляешь, что будет за результат если каждый возьмется за работу. I>А для случаев более серьезных, придется искать способ численно выразить Васю чрез Колю, потому ты снова приходишь к численным характеристикам.
Пол сотни программистов, шесть воркстримов на проекте — это достаточно серьёзный случай?
Был у меня лет семь назад такой случай В IBM. Был у нас в команде один индусик. Его вклад в общее дело (в команде с пятью программистами) составлял где-то 5%, а количество его багов в треккере — 80%. После того как его выгнали за неуспеваемость, его код был за неделю переписан и баги исчезли. Как численно выразить этого индуса? Особенно интересно увидеть в формуле зависимость того, что после его увольнения и фактического сокращения поголовья команды, картина через призму багтреккера стала выглядеть в пять раз лучше.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
I>С численными характеристиками одна проблема, их нельзя рассматривать по отдельности. I>Нужна оценочная функция, которая у тебя вобщем то уже есть, только ьы пользуешься ею интуитивно.
Нет у меня никакой функции. И быть не может. Во-первых, я не менеджер и такие функции меня не интересуют в принципе. Во-вторых, более менее правдоподобные функции можно получить для конкретного типа задач конкретной командой. Я не решая по два раза одни и теже задачи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
IT>>>А что такое трудоёмкость? Мы её будем мерять в человеках? А может гораздо точнее будет в Васях или Колях? I>>С Васями и Колями хорошо, когда у тебя есть один Вася и один Коля и ты интуитивно представляешь, что будет за результат если каждый возьмется за работу. I>>А для случаев более серьезных, придется искать способ численно выразить Васю чрез Колю, потому ты снова приходишь к численным характеристикам.
IT>Пол сотни программистов, шесть воркстримов на проекте — это достаточно серьёзный случай?
IT>Был у меня лет семь назад такой случай В IBM. Был у нас в команде один индусик. Его вклад в общее дело (в команде с пятью программистами) составлял где-то 5%, а количество его багов в треккере — 80%. После того как его выгнали за неуспеваемость, его код был за неделю переписан и баги исчезли. Как численно выразить этого индуса? Особенно интересно увидеть в формуле зависимость того, что после его увольнения и фактического сокращения поголовья команды, картина через призму багтреккера стала выглядеть в пять раз лучше.
Я не совсем понимаю, что ты имел сказать. Сначала "Как численно выразить индуса" а потом "в пять раз лучше"
Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
Т.е. как то ты ухитряешься конвертиорвать васей в колей, но поделиться этим не можешь. Об чем тебе Гапертон и говорит
Здравствуйте, IT, Вы писали: IT>Глупость — не только последнее, а вообще любое использование метрик. IT>Статистическое исследование подразумевает как минимум необходимость понаблюдать за процессом. Т.е. мы получим какие-то данные после того как уже будет поздно пить боржоми. Какой мне толк от знания того, что на решение задачи X с помощью технологии Y было затрачено Z Васе-Коле-Вите-часов, если в следующий раз я буду решать задачу A, используя технологию B и привлеку для её решения Петю и Ваню?
Ну вот это ты зря. Все общественные науки — типа того же менеджмента — занимаются ровно этим.
Берут одни кренделя и делают опросы тим мемберов в командах. Публикуют их, вместе с метриками чего-нибудь высокоабстрактного.
Потом какие-нибудь другие кренделя сводят все эти публикации и пишут монографию типа "мы обследовали семь педеровых компаний в области IT и заметили, что при применении X программисты в среднем в 2.34 раза чаще употребляют слово ".пт", чем аналитики при применении Y употребляют слово ".па". И из этого мы можем сделать вывод о том, что в XXI веке технологии управления проектами Z, W, и U устарели. В нашем быстроменяющемся рынке повысить удовлетворённость потребителей и надои трафика на квадратный байт можно только при помощи новой, альтернативной парадигмы управления, построенной на расширении полномочий и вовлечении работников. Процесс развития делегировния ответственности должен быть длительным, непрерывным, и незаметным, как зарытый в землю шланг". И так далее. Подобная писанина приносит $ на kLOC гораздо больше, чем любое программирование.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
I>>С численными характеристиками одна проблема, их нельзя рассматривать по отдельности. I>>Нужна оценочная функция, которая у тебя вобщем то уже есть, только ьы пользуешься ею интуитивно.
IT>Нет у меня никакой функции. И быть не может.
Тут я тебе не поверю. Рассказ про индуса категорически свидетельствует о том, что обозначеная функция у тебя есть.
> Во-первых, я не менеджер и такие функции меня не интересуют в принципе.
Собственно по этому у тебя интуитивный подход в этом плане.
>Во-вторых, более менее правдоподобные функции можно получить для конкретного типа задач конкретной командой. Я не решая по два раза одни и теже задачи.
Одни и те же не обязательно. Можно даже похожие. Вообще редко получаются задачи абсолютно уникальные, ты ведь не менял область деятельности радикально ?
Здравствуйте, gandjustas, Вы писали:
G>А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода.
Это не сложность проекта. Это сложность для HR найти нужного человека.
G>Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
G>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
В каком-то смысле можно считать эту "сложность" именно той сложностью, которая "сложность в отличие от трудоёмкости". Классический пример: выкопать яму объемом десять кубов не сложно, но трудоёмко.
Придумать новый алгоритм сортировки — сложно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
G>>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
S>В каком-то смысле можно считать эту "сложность" именно той сложностью, которая "сложность в отличие от трудоёмкости". Классический пример: выкопать яму объемом десять кубов не сложно, но трудоёмко. S>Придумать новый алгоритм сортировки — сложно.
Мне кажется не стоит делить сложность и трудоемкость так, как ты это делаешь.
Грубо говоря, все сводится к уровню мышления, не знаю какой термин подобрать.
Копать яму — это значит, что техника тебе давным давно известна, опробована, отработана и дело только в примнении ранее полученых навыков.
Придумать алгоритм — это вобщем то тоже техника, которая может быть опробована, отработана и дело только в применении ранее полученых навыков.
Разница только в смысловой дистанции. Чем больше эта дистанция, тем "сложнее" задача.
Но это все относительно и субъективно — человек, которы съел собаку на конкретных задачах, будет выдавать просто адские решения и ему это, вполне возможно, будет ни чуть не сложно.
Соответсвенно чем лучше отработана техника, тем бОльшими абстрациями ты можешь оперировать в единицу времени без потери например точности. Т.е., уровень детализации ты можешь менять в достаточно широких пределах.
Здравствуйте, Ikemefula, Вы писали:
I>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю". С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
— импосибл,
— только если включить форсаж,
— бу сделано,
— фигня вопрос.
При этом всегда присутствует оговорка, что это всё при отсутствии непредвиденных обстоятельств АКА мистической хреноты.
I>Т.е. как то ты ухитряешься конвертиорвать васей в колей, но поделиться этим не можешь. Об чем тебе Гапертон и говорит
Гапертон вообще говорит о чём-то своём. Он изобрёл метрику, в которой в качестве попугаев используются ошибки. Я несказанно рад за него и ни чуточки не сомневаюсь, что эта метрика замечательно работает в его команде, на его проектах, при используемых им технологиях для оценки его рисков и сроков выполнения его работ. Только, во-первых, это всё его субъективный взгяд на его собственные проблемы, а, во-вторых, статья совсем не об этом. Обрати внимание, говоря о сложности, Гапертон всё время соскакивает на трудоёмкость. Он менеджер, он видит сложность только с этой стороны. В принципе, это нормально. У менеджеров свои задачи, которые они должны решать и за которые они несут ответственность в первую очередь. У программистов свои задачи, немного другие. К сожалению, очень часто эти задачи не совпадают и даже конфликтуют между собой.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, minorlogic, Вы писали:
M>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом." M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Надеюсь ты в обморок от переизбытка чувств не упал как князь Мышкин? Ну вот и славно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Gaperton, Вы писали:
IT>>Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки? G>Бесполезной фигней являются общие рассуждения о "сложности". Никаких полезных выводов из этого сделать нельзя. You can't control what you can't measure.
Вынужден с тобой не согласиться. Для меня бесполезной фигнёй являются цифры, которыми измеряются абстрактные человекочасы абстрактного проекта. Общие рассуждения о сложности позволяют мне принять решения на распутье: направо пойдешь коня потеряешь, прямо пойдешь голову потеряешь, налево пойдешь жену потеряешь. В этом во всём понятно только одно — налево лучше не ходить. А куда тогда? И таких решений мне нужно принимать десятки каждый день, а не одно один раз за весь проект, как тебе кажется.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
I>>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
IT>Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю". С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
IT>- импосибл, IT>- только если включить форсаж, IT>- бу сделано, IT>- фигня вопрос.
То есть у тебя таки есть оценка времени выполнения, только ты сам её не говоришь. Для инженеров это нормальное явление так как многие считают что назвав оценку они берут ответственность за риски на себя.
IT>При этом всегда присутствует оговорка, что это всё при отсутствии непредвиденных обстоятельств АКА мистической хреноты.
Это и есть те самые риски
В принципе ты можешь сам называть срок "только если включить форсаж" и "фигня вопрос", как нижнюю и верхнюю границу времени выполнения. С теми же оговорками про риски.
I>>Т.е. как то ты ухитряешься конвертиорвать васей в колей, но поделиться этим не можешь. Об чем тебе Гапертон и говорит
IT>Гапертон вообще говорит о чём-то своём. Он изобрёл метрику, в которой в качестве попугаев используются ошибки. Я несказанно рад за него и ни чуточки не сомневаюсь, что эта метрика замечательно работает в его команде, на его проектах, при используемых им технологиях для оценки его рисков и сроков выполнения его работ. Только, во-первых, это всё его субъективный взгяд на его собственные проблемы, а, во-вторых, статья совсем не об этом. Обрати внимание, говоря о сложности, Гапертон всё время соскакивает на трудоёмкость. Он менеджер, он видит сложность только с этой стороны.
Трудоемкость — функция сложности. Все параметры "сложности" так или иначе выражаются в характеристиках трудоемкости. А при некотором объеме статистики по этим параметрам уже можно выявить закономерности.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ikemefula, Вы писали:
I>>Сто пудов, у тебя есть как минимум интуитивная оценочная функция и надо чуток поработать, что бы можно было сформули ровать внятно, по-человечески.
IT>Если ты имеешь ввиду оценочную функцию производительности труда, то такой функции у меня нет. Я более двадцати лет пишу код и когда сегодня мне мой начальник задаёт вопрос "сколько это займёт времени", то я однозначно отвечаю — "не знаю".
Ты меня пугаешь. Вроде мы с тобой ровесники, если общие знакомые не врут, 20 лет не совсем представляю откуда берутся
>С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
Я это понимаю. Но это ведь для тех случав, когда работа радикально отличается от тех что были раньше ? Или ты имеешь скзать, что тебя ставят на проекты на которых другие уже провалили всё подряд ?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
IT>>>Ну да. А может лучше сразу не заниматься такой бесполезной фигнёй как формальные выкладки? G>>Бесполезной фигней являются общие рассуждения о "сложности". Никаких полезных выводов из этого сделать нельзя. You can't control what you can't measure.
IT>Вынужден с тобой не согласиться. Для меня бесполезной фигнёй являются цифры, которыми измеряются абстрактные человекочасы абстрактного проекта.
Так же, как и показания спидометра абстрактной машины на абстрактной трассе являются полной фигней. И что? Кто тебя заставляет говорить об абстракциях-то рассуждать?
Конкретные человекочасы конкретного проекта — вовсе не фигня. Ибо в значительной степени определяют его, конкретного проекта, не менее конкретный бюджет. При значительном превышении которого твои рассуждения о видах сложности в этом проекте внезапно перестанут кого-либо интересовать — ибо проект будет закрыт.
IT>Общие рассуждения о сложности позволяют мне принять решения на распутье: направо пойдешь коня потеряешь, прямо пойдешь голову потеряешь, налево пойдешь жену потеряешь. В этом во всём понятно только одно — налево лучше не ходить. А куда тогда? И таких решений мне нужно принимать десятки каждый день, а не одно один раз за весь проект, как тебе кажется.
Точно так же, решение тебе помогают принять не "общие рассуждения", а конкретные рассуждения о конкретной сложности в конкретном проекте.
То, что ты в своих рассуждениях ввел разнообразные факторы — это неплохо. Это лучше, чем просто говорить "сложно". Но непосредственно из этого ничего не следует, ибо с проектным управлением твои рассуждения не стыкуются. Они не уложены в систему. Рассуждать, в результате, ты не можешь — ты можешь только пользоваться "чуйкой".
Здравствуйте, gandjustas, Вы писали:
IT>>С другой стороны, я могу задать встречный вопрос — "а сколько у меня есть времени", и, в зависимости от его ответа, я могу ответить одно из:
IT>>- импосибл, IT>>- только если включить форсаж, IT>>- бу сделано, IT>>- фигня вопрос.
G>То есть у тебя таки есть оценка времени выполнения, только ты сам её не говоришь.
Здравствуйте, IT, Вы писали:
T>>>>Если возвращаться к теме статьи, то ты не определил количественную меру сложности, поэтому не можешь сформулировать и закона сохранения IT>>>Не определил по одной простой причине — её не существует. G>>По одной простой причине — ты не настолько хорошо понимаешь проблему, чтобы определить количественную меру.
IT>100% не настолько хорошо. Хорошо если хотя бы на 0.5%.
Я это сказал только к тому, что очень тяжело доказать не существование чего-либо. Приведенная мной фраза — более честна, штоли.
IT>>>Блин, ещё один измеряльщик. Ну тогда сравни мне сложность восприятия безобразно оформленного кода, алгоритмическую сложность кода, объём кода, сложность обучения, необходимую для понимания кода, и сложность понимания поставленной задачи. При этом, желательно, чтобы формула была универсальной для любого программиста. G>>Техника работы с метриками основана на измерениях, сравнениях, анализе истории и поиске статистических закономерностей, а не "универсальных формулах для любого программиста".
IT>К сожалению, метрики никак не помогают мне при принятии решений, которые я как программист принимаю десятками ежедневно. А из этих решений в конце концов складывается результат, который может быть потом и можно как-то померить.
Метрики — они как спидометр, тахометр, и прочие приборы на доске автомобиля. В них самих по себе особой магии нет, и их наличие не позволяет алгоритмизовать управление автомобилем. Но — при принятии решений они _полезны_.
G>>Последнее — глупость.
IT>Глупость — не только последнее, а вообще любое использование метрик.
Ну, если у тебя есть автомобиль, то ты регулярно используешь метрики . С неработающей приборной доской в автомобиле ты даже не поймешь, что у тебя заканчивается бензин. С работающей — ты поймешь, что тебе надо бы на заправку зарулить, и увидев знак "это единственная заправка на 100 миль" ты туда завернешь.
G>>Для твоего случая — время на объем, плюс процентная раскладка времени на каждый этап. Вводи по очереди разные факторы, и проведи статистическое исследование, если тебе интересно. Мне предложенное тобой сравнение кажется лишенным какой-ли практической пользы. Так, абстрактное умствование.
IT>Статистическое исследование подразумевает как минимум необходимость понаблюдать за процессом.
Вообще говоря — верно. Но в принципе — не обязательно. Много чего можно собрать и постфактум, по уже завершенным проектам.
IT>Т.е. мы получим какие-то данные после того как уже будет поздно пить боржоми.
Нет, конечно. Мы будем использовать метрики, собранные в реальном времени, и сравнивать их с планом. А план составлять с оглядкой на историю.
Простейший пример — так называемый EV-Plan.
Составил план работ. Нарисовал кривую — общее количество (нарастающим итогом) закрытых задач понедельно, на основании плана. И каждую неделю наносишь на этот же график новую точку фактической кривой — с общим количеством фактически закрытых задач.
Вот тебе пример самого простого использования самой незамысловатой метрики. Ты не просто заметишь отставание по этому графику — ты в состоянии увидеть нарастающее отставание. И понять, что в плане систематическая недооценка. И сделать перепланирование, сдвинув сроки, или зарезав функциональность.
Глядя на разного рода гант-чарты — ты этого так просто не увидишь.
IT>Какой мне толк от знания того, что на решение задачи X с помощью технологии Y было затрачено Z Васе-Коле-Вите-часов, если в следующий раз я буду решать задачу A, используя технологию B и привлеку для её решения Петю и Ваню?
Пока не умеешь метриками пользоваться — никакого. Если умеешь — очень большой толк. Сходу этого, естественно, не поймешь — этому учиться надо.
В твоем случае — возьмешь метрики Пети и Вани, делов-то. И не надо рассказывать, что каждая новая задача у тебя на новой неизвестной технологии и языке программирования делается — это не так. Для прогноза берется не время на отдельной задаче, а средний коридор "продуктивности".
Далее, делаешь простую штуку. Планируешь время и объем. Считаешь запланированную продуктивность делением одного на другое, и:
— убеждаешься, что попал в коридор, а не вылетел из него.
— Смотришь на положение значения в коридоре, и следишь, что оно отражает твое представление о сложности.
Если указанное не выполняется — ты где-то ошибся в прогнозе, правь.
Я тебе простейший вариант планирования с учетом метрик дал. Есть другие.
Что до разброса времени на отдельных задачах — это неважно. Также не важно, что по отдельным задачам прогноз не совпадет. Они тебя не интересуют — важна суммарная оценка по проекту. Время решения задачи трактуется как случайная величина. И процентная дисперсия суммы этих величин будет уменьшаться при росте единиц планирования. Означает это одно — погрешности оценок будут взаимоуничтожены, если ты прогнозом попал в матожидание.
Здравствуйте, Sinclair, Вы писали:
>Потом какие-нибудь другие кренделя сводят все эти публикации и пишут монографию типа "мы обследовали семь педеровых компаний в области IT и заметили, что при применении X программисты в среднем в 2.34 раза чаще употребляют слово ".пт", чем аналитики при применении Y употребляют слово ".па". И из этого мы можем сделать вывод о том, что в XXI веке технологии управления проектами Z, W, и U устарели. В нашем быстроменяющемся рынке повысить удовлетворённость потребителей и надои трафика на квадратный байт можно только при помощи новой, альтернативной парадигмы управления, построенной на расширении полномочий и вовлечении работников. Процесс развития делегировния ответственности должен быть длительным, непрерывным, и незаметным, как зарытый в землю шланг". И так далее. Подобная писанина приносит $ на kLOC гораздо больше, чем любое программирование.
Какая милая фантазия о содержимом монографий, которых не читал .
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>А как тут учитывается "сложность" связанная с необходимым объемом знания для написания кода. S>Это не сложность проекта. Это сложность для HR найти нужного человека.
G>>Гипотетический пример — написать парсер языка без специальных инструментов. Влоб такая задача решается крайне плохо, используя некоторые теоретически знания — гораздо лучше.
G>>Многие современные языки как раз торгуют объем-время на эту самую сложность понимания.
S>В каком-то смысле можно считать эту "сложность" именно той сложностью, которая "сложность в отличие от трудоёмкости". Классический пример: выкопать яму объемом десять кубов не сложно, но трудоёмко. S>Придумать новый алгоритм сортировки — сложно.
Все правильно.
Трудоемкость характеризует объем работ. Выкопать яму объемом 20 кубов (при прочих равных — при условии того же грунта, исполнителя, инструментов, и т.п.) вдвое затратнее, чем 10 кубов. Реализовать 20 "одинаковых по сложности" независимых фич — при прочих равных в два раза затратнее, чем 10.
"Сложность" работ характеризует производительность труда, т.н. "продуктивность", которая есть "объем на время".
Т.е. 10 кубов песка выкопать гораздо "проще", чем 10 кубов глины, ибо мы будем копать песок в темпе побыстрее, чем глину.
Так же и с сортировкой. Выдумать и сделать новый алгоритм сортировки вообще говоря _дольше_, чем реализовать существующий, при равном размере кода. Т.е. "показатель строки кода в час" на задаче, где надо что-то выдумывать, будет вообще говоря _меньше_. Если предположить, что задача изолирована, и исключить таким образом влияние других факторов. Фактор внесения изменений в существующий код учитывается цикломатикой и связностью.
Берем _простейшую_ производную метрику — и она количественно характеризует этот подвид "сложности".
Эту "сложность" можно и _запланировать_, сделав, например, не только прогноз срока, но и одновременно прогноз объема.
Основная же ценность системы метрик — в том, что люди понимают взаимосвязь. Это понимание ценно и в том случае, если метрики не применять. Ибо закономерности работают независимо от того, проводишь ты измерения, или нет.
Здравствуйте, minorlogic, Вы писали:
M>"Трансформирование сложности означает одну простую вещь – устраняя сложность в одном месте, мы всегда добавляем её где-то в другом."
M>Очевиднейший бред, дальше читать не стал. И как только такой треш пропускает рецензура...
Один ошибочный вывод не делает бредом всю статью. В конце концов, непрерывно нести бред очень тяжело. Почти так же тяжело, как и все время говорить истину, и только истину . Если предмет статьи содержателен, конечно.
Если нам не помогут, то мы тоже никого не пощадим.
В IBM. Был у нас в команде один индусик. Его вклад в общее дело (в команде с пятью программистами) составлял где-то 5%, а количество его багов в треккере — 80%. После того как его выгнали за неуспеваемость, его код был за неделю переписан и баги исчезли. Как численно выразить этого индуса? Особенно интересно увидеть в формуле зависимость того, что после его увольнения и фактического сокращения поголовья команды, картина через призму багтреккера стала выглядеть в пять раз лучше.
