Почему методы разработки не отражают исследовательские данные? - PullRequest
2 голосов
/ 30 октября 2009

Это был главный вопрос, поставленный «битами улик» Грега Уилсона . Я перефразирую свой вопрос здесь, поэтому, пожалуйста, прочитайте презентацию для всех деталей.

Я также хотел бы знать, если вы не согласны с предпосылкой вопроса, т. Е. Вы думаете, что современные практики разработки на самом деле делают отражают доказательства.

Ответы [ 4 ]

3 голосов
/ 30 октября 2009

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

Например, точно так же, как в экспериментальной психологии, но даже более того, многие такие эмпирические исследования (например, Пречелта, как указано в презентации) основаны на добровольцах (и любой статистик может сказать вам, что при использовании самостоятельно выбранной выборки полностью искажает результаты и делает все исследование по существу бесполезным) и / или студентов (и, может быть, профессиональный опыт на 5, 10 или 20 лет не имеет большого значения для результатов - т. е. можно слепо предполагать, что опыт слепо не имеет значения, чтобы профессионалы ничему не научились на этом, что могло бы повлиять на результаты?).

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

Вы могли бы сделать это (получить случайную выборку) в структуре, способной к принуждению - когда отказ от участия в исследовании, когда случайным образом выбранная часть выборки может нести возмездие (большинство фирм было бы в таком положении, и, безусловно, так было бы, например, наряды для военного программирования). У вас могут быть некоторые ворчащие, не очень желающие участники, но это более или менее неизбежно. Фирма с, скажем, 1000 программистами, может получить случайную выборку из 100 из них для участия в течение двух дней - этого будет достаточно для некоторых исследований, хотя определенно не для многих из самых интересных среди тех, которые были указаны (например, о влиянии различных этапов цикла разработки) и репрезентативной выборке программистов, работающих в настоящее время в фирме.

Стоимость для фирмы (с учетом полной загрузки сотрудников и затрат на инфраструктуру) может составлять около 100 000 долларов. Как окупятся инвестиции фирмы? Если результаты исследования не могут быть эффективно сохранены в тайне (маловероятно, что так много людей вовлечены, и исследователи не захотят их публиковать?), «Повышение производительности программистов» (возможно, путем изменения практики на основе исследования) не является реальным ответом. потому что все конкуренты фирмы (по крайней мере, с аналогичным населением и практикой программистов) могут легко имитировать любые успешные инновации. (Надеюсь и верю, что такие результаты не будут патентоспособными! -).

Таким образом, исследования, основанные на студентах и ​​/ или добровольцах, очень короткие исследования и просто наблюдательный (что не такое же, как эмпирический ! -) те, которые больше всего вокруг. Если вам не ясна разница между наблюдением и эмпирическим исследованием: на протяжении большей части истории человечества люди были убеждены, что тяжелые предметы падают быстрее, основываясь на данных наблюдений; потребовались преднамеренные эксперименты (созданные Галилеем для сравнения скоростей падения при попытке уменьшить некоторые эффекты, с которыми Галилео фактически не мог справиться строго), то есть эмпирические данные, чтобы изменить мнения по этому вопросу.

Это не совсем бесполезное свидетельство, но оно немного слабовато - 1026 * - один набор полуубедительных точек данных из многих, которые должны взвешивать руководители, принимающие решения, но только до определенной степени. Скажем, есть это исследование, основанное где-то на студентах, или на добровольцах из сети, или даже на надлежащей выборке из 100 человек ... из компании, которая делает программное обеспечение совершенно отличным от моего, и, на мой взгляд, нанимает посредственных программистов; как я должен взвесить эти исследования по сравнению с моими собственными наблюдательными данными, основанными на точных знаниях конкретных секторов, технологий и людей, с которыми работает моя фирма ? «Несколько» кажется разумным наречием для использования здесь; -)

2 голосов
/ 30 октября 2009

Потому что ...

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

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

Соответствующие метрики относительно любой сложной системы найти сложно. Это связано с тем, что многочисленные части сложной системы предоставляют еще большее число возможных параметров для измерения, утверждения, сравнения. Это также, возможно, главным образом, из-за высокого уровня корреляции между этими различными метриками. Проектирование ПО не является исключением, с тысячами технологических предложений, сотнями языков, десятками методологий и многими факторами, выходящими за рамки самой дисциплины, трудно найти эффективные показатели. Кроме того, многие из факторов в игре имеют дискретный / качественный характер и, следовательно, менее легко подвергаются числовой интеграции. Неудивительно, что о «количестве строк кодов» все еще много говорят; -)

Легко найти много случаев, когда конкретные исследования (или, действительно, конкретные рецензии некоторых "консалтинговых организаций") спонсируются в контексте определенного продукта или конкретной отрасли. . Например, люди, продающие инструменты отладки, будут склонны переоценивать процент времени, затрачиваемого на эту функцию, по сравнению с общим временем разработки и т. Д. Люди, продающие профилировщики ...

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

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

Лично я давно выступаю за использование основанного на фактических данных чего-либо , и я рад жить во времена, когда онлайн-технологии, вычислительная мощность и общие математические основы объединяются для предоставления множество возможностей в различных областях, включая, но не ограничиваясь, областью разработки программного обеспечения.

0 голосов
/ 30 октября 2009

Интересная презентация!

Действительно трудно (и очень дорого) проводить контролируемые эксперименты, которые являются достаточно большими и достаточно реальными, чтобы убедить практикующих. В течение нескольких часов вы, как правило, проводите небольшие эксперименты с участием 20 аспирантов, когда нам действительно нужно измерить команды опытных разработчиков, работающих в течение нескольких недель или месяцев над одной и той же задачей в разных условиях (см. Слайд 12). И, конечно, последние исследования очень дороги.

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

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

0 голосов
/ 30 октября 2009

Потому что принятие решений, противоречащих общепринятому мнению, рискованно.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...