Насколько плох SLOC (строки исходного кода) как метрика? [закрыто]

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

Однако цель этого упражнения - раскрыть вещи для нашего руководства проектами в терминах, которые они могут понять. В частности, этим нетехническим менеджерам нужны метрики, которые они могут понять.

Я хорошо понимаю наши варианты метрик и предложил весь набор (два моих любимых - выполненные требования и фактические затраты в сравнении с запланированными). Тем не мение, у нас действительно есть старые руки, и они, как правило, держатся за такие показатели, как SLOC.

Я понимаю искушение SLOC: людям, не занимающимся программным обеспечением, его легко понять, и он кажется ближайшим аналогом физического объекта (это как в старые времена считать перфокарты!).

вот вопрос: как я могу объяснить опасность SLOC нетехническому человеку?

Вот конкретная мотивация: мы работаем над довольно зрелой развернутой системой, за которой стоят годы истории. По мере добавления функций SLOC имеет тенденцию оставаться примерно на уровне или даже уменьшаться (рефакторинг удаляет старый / мертвый код, новые функции на самом деле являются просто корректировкой существующего и т. Д.). Для менеджера, не являющегося программистом, нерастущий SLOC в проекте разработки в лучшем случае сбивает с толку ....

Пояснение в ответ на недавний ответ ниже: помните, я утверждаю, что SLOC - плохая метрика для измерения прогресса проекта. Я не утверждаю, что это число не стоит собирать. Он требует обширного контекста, чтобы делать с ним что-нибудь полезное, а у большинства менеджеров программ этот контекст отсутствует.