Некоторые люди просили больше информации о том, откуда взялось название этого блога «10x». Суть названия в том, что исследователи обнаружили 10-кратную разницу в производительности и качестве между разными программистами с одинаковым уровнем опыта, а также между разными командами, работающими в одних и тех же отраслях.
Первоначальное исследование, которое обнаружило огромные различия в индивидуальной производительности программирования, было проведено в конце 1960-х годов Сэкманом, Эриксоном и Грантом (1968). Они изучали профессиональных программистов со средним опытом 7 лет и обнаружили, что соотношение начального времени кодирования между лучшими и худшими программистами было примерно 20 к 1; соотношение времени отладки более 25 к 1; размера программы 5 к 1; и скорости выполнения программы около 10 к 1. Они не обнаружили никакой связи между количеством опыта программиста и качеством кода или производительностью.
Детальное изучение результатов Сэкмана, Эриксона и Гранта показывает некоторые недостатки в их методологии (включая объединение результатов программистов, работающих на языках программирования низкого уровня, с результатами программистов, работающих на языках программирования высокого уровня). Однако даже после учета недостатков их данные все еще показывают более чем 10-кратную разницу между лучшими программистами и худшими.
За годы, прошедшие с момента проведения первоначального исследования, общий вывод о том, что «среди программистов существуют различия по порядку величины», был подтвержден многими другими исследованиями профессиональных программистов (Кертис, 1981 г., Миллс, 1983 г., ДеМарко и Листер, 1985 г., Кертис и др., 1986 г., Кард, 1987 г., Бём и Папаччио, 1988 г., Валетт и МакГарри, 1989 г., Бём и др., 2000 г.).
Также есть много анекдотических подтверждений большой разницы между программистами. Во время моей работы в Boeing в середине 1980-х годов был проект, над которым работало около 80 программистов, и который рисковал пропустить критический срок. Проект был критически важен для Boeing, поэтому они перевели большую часть из 80 человек с этого проекта и наняли одного парня , который закончил все кодирование и поставил программное обеспечение вовремя. Я не работал над этим проектом и не знал этого парня, поэтому я не уверен на 100%, что эта история правдива. Но я услышал эту историю от человека, которому доверял, и в то время она казалась правдой.
Такая степень вариативности свойственна не только программному обеспечению. Исследование Норма Августина показало, что в различных профессиях — писательстве, футболе, изобретательстве, работе в полиции и других — 20 процентов лучших людей производят около 50 процентов продукции, будь то тачдауны, патенты, раскрытые дела или программное обеспечение (Augustine 1979). Если задуматься, это просто имеет смысл. Мы все знаем людей, которые являются исключительными студентами, исключительными спортсменами, исключительными художниками, исключительными родителями — эти различия являются лишь частью человеческого опыта; почему мы должны ожидать, что разработка программного обеспечения будет отличаться?
Учёт крайних случаев в статистике
Исследование Августина показало, что, поскольку некоторые люди не вносят никакого ощутимого вклада (квотербеки, которые не делают тачдаунов, изобретатели, не владеющие патентами, детективы, которые не закрывают дела, и т. д.), данные, вероятно, занижают фактическую разницу в производительности.
Похоже, это верно для программного обеспечения. В нескольких опубликованных исследованиях производительности программного обеспечения около 10% субъектов экспериментов не смогли выполнить экспериментальное задание. В исследованиях в записях говорится: «Поэтому результаты этих экспериментальных субъектов были исключены из нашего набора данных». Но в реальной жизни, если кто-то «не выполнил задание», вы не можете просто «исключить его результаты из набора данных». Вам нужно дождаться, пока он закончит, назначить кого-то другого для выполнения его работы и так далее. Интересный (и пугающий) вывод из этого заключается в том, что около 10% людей, работающих в сфере программного обеспечения, на самом деле могут вносить *негативный& вклад в производительность своих проектов. Опять же, это хорошо согласуется с реальным опытом. Я думаю, многие из нас могут вспомнить конкретных людей, с которыми мы работали, которые подходят под это описание.
Изменение производительности команды при разработке программного обеспечения
Эксперты по программному обеспечению давно заметили, что производительность команды варьируется примерно так же, как и производительность отдельного человека — на порядок (Mills 1983). Частично это объясняется тем, что хорошие программисты, как правило, группируются в одних организациях, а плохие программисты — в других, и это наблюдение было подтверждено исследованием 166 профессиональных программистов из 18 организаций (Demarco and Lister 1999).
В одном исследовании семи идентичных проектов затраченные усилия различались в 3,4 раза, а размеры программ — в 3 раза (Boehm, Gray и Seewaldt 1984). Несмотря на диапазон производительности, программисты в этом исследовании не были разнообразной группой. Все они были профессиональными программистами с несколькими годами опыта, которые были зачислены в аспирантуру по компьютерным наукам. Разумно предположить, что исследование менее однородной группы выявило бы еще большие различия.
Более раннее исследование команд программистов выявило разницу в размере программы в 5 раз и разницу во времени, необходимом команде для завершения одного и того же проекта, в 2,6 раза (Вайнберг и Шульман, 1974).
После анализа данных за более чем 20 лет при построении модели оценки Cocomo II Барри Бём и другие исследователи пришли к выводу, что разработка программы с командой, находящейся в 15-м процентиле программистов, ранжированных по способностям, обычно требует примерно в 3,5 раза больше человеко-месяцев, чем разработка программы с командой, находящейся в 90-м процентиле (Бём и др., 2000). Разница будет намного больше, если одна команда более опытна, чем другая, в языке программирования или в прикладной области, или в обоих.
Конкретные случаи
Одной из конкретных точек данных является разница в производительности команд разработки между Lotus 1-2-3 версии 3 и Microsoft Excel 3.0. Оба были настольными приложениями для работы с электронными таблицами, завершенными в период с 1989 по 1990 год. Случаи, когда две компании публикуют данные по таким похожим проектам, встречаются редко, что делает это прямое сравнение особенно интересным. Результаты этих двух проектов были следующими: Excel потребовалось 50 человеко-лет для создания 649 000 строк кода. Lotus 123 потребовалось 260 человеко-лет для создания 400 000 строк кода. Команда Excel создала около 13 000 строк кода за год работы персонала. Команда Lotus создала 1500 строк кода за год работы персонала. Разница в производительности между двумя командами составила более 8 раз, что подтверждает общее утверждение о различиях в порядке величины не только между разными людьми, но и между разными проектными командами.
Что вы видели?
Видели ли вы разницу в возможностях 10:1 между разными людьми? Между разными командами? Насколько лучший программист, с которым вы работали, был лучше худшего? Охватывает ли диапазон 10:1?
Комментарии (46)
ihouser
16.02.2025 11:04Ну а теперь признавайтесь, кто из вас так сильно не хочет работать на Маска в SpaceX?
GospodinKolhoznik
16.02.2025 11:04Excel был написан на Си. Lotus писали на Ассемблере. Всякий кто пробовал писать на ассемблере подтвердит, что писать на нём получается годаздо медленнее, чем на Си. Этот случай стал настолько известен, что вскоре все компании отказались от разработки на ассемблере и перешли на языки более высокого уровня.
Дело вовсе не в том, что Excel писала команда Дартаньянов. Просто неудачный выбор стека разработки.
pecheny
16.02.2025 11:04Дело вовсе не в том, что Excel писала команда Дартаньянов. Просто неудачный выбор стека разработки.
Измерять продуктивность в количестве строк, особенно в современном мире – вообще довольно сумеречная практика.
Я считаю, на больших и сложных проектах вообще, лучшие по импакту программисты могут создавать отрицательное количество строк. Примерно, как из комментария ниже, хотя может чуть более масштабно. Когда навернуто в легаси параллельных систем, которые делают примерно одно, но чуть-чуть по-разному, и при этом и требований уже не сохранилось, а команда двигается с черепашей скоростью, пытаясь это развивать и не сломать... Тот, кто сможет обобщить и вербализовать требования, а потом собрать их в одну понятную систему – вот он может считаться 10х. Если после его работы команда будет выдавать в 10 раз фичей в единицу времени больше, чем до.
А если немного более серьезно, то я бы называл десятикратниками тех, кто может создавать архитектурные решения, что с одной стророны просты и дешевы в разработке под текущие требования, с другой – как бы ни поменялись требования, можно было не "ну теперь полпроекта переписывать, у нас так не предусмотрено", а из тех же кусков и модулей можно было собрать быстро и дешево по-новому.
Или, в определенных ситуациях (когда модель бизнеса позволяет), десятикратник это тот, кто может выдавать фичей как команда из 10 человек. Но при этом, не масштабируясь. Например благодаря мощным но очень хитрым инструментам/стеку. Ну там, когда метапрограммирование какое-нибудь применяется. Или что-нибудь очень динамическое. Или наоборот безопасное.Dhwtj Автор
16.02.2025 11:04Вот!
Поэтому я и хочу и немножко могу быть архитектором.
Достаточно открыть книжку чистая архитектура и ужаснуться графику падения производительности с ростом сложности проекта - он на первых страницах. Но это является важным только для больших проектов от 3-10 человеко лет, когда работает команда или несколько, уже ушли те кто создавали основу приложения и все уже боятся чего-то менять
ooprizrakoo
16.02.2025 11:04Один мой бывший коллега как-то на заказ сделал небольшую флешовую мини-игрушку на AS3 (год примерно 2007-8). Делал игру по шаблонным тимплейтам, на готовом фреймворке или с готовыми либами, т.к. компания-заказчик делала такие игрушки сотнями, в основном нанимая прогеров из Индии.
Но товарищ не просто сделал игрушку эту, но и отрефакторил какие-то неоптимальности, в результате чего игрушка стала весить раза в четыре меньше, а работать примерно в 10 раз быстрее (по плавности-безлаговости) по сравнению с аналогичными игрушками компании. Компания-заказчик сказала "Не, не надо чтоб игрушка так быстро работала, а то спросят почему другие игрушки такие тормозные". И ему пришлось добавлять в игрушку какие-то ненужные-пустые циклы, чтобы её замедлить, чтобы работала так же тормозно, как другие.
А индийский код в то время писали как раз исходя из количества написанных строк. Там внутри были поэмы лесенкой, в стиле Маяковского.
(пример взял из интернета. тут по-идее return ещё можно писать с новой строки, в два раза увеличив личную эффективность ;)
DancingOnWater
Люди разные, способности у них тоже разные. Кто- то может поднять штангу в 300 кг, а вот бег на 100 метров ему не дается.
Я вот знаю человека, который по продуктивности, в силу возраста, хуже всех. Но без него некоторые задачи либо просто не решаются, либо решаются сильно хуже.
Моя слабая сторона - ляпы на ровном месте. Лично мой ответ на это - полнее тестирование и глубже проработанность архитектуры. В итоге выкатка фичи занимают дольше времени, но дальнейшее ее развитие сильно ускоряется.
И так всегда и везде. Я за 15 лет работы ни разу не видел человека сильнее меня хотя бы в 2 раза и хотя бы в половине направлений.
Dhwtj Автор
Мне кажется, зависит больше от продукта, требований к тестированию, наличию легаси. Встречал продукты сопровождение которых просто геморрой.