Знаете ли вы, что за все годы существования индустрии разработки ПО не было выявлено сильной связи межу опытом работы и качеством кода и продуктивностью сотрудника?
В 1968 году было проведено исследование продуктивности работы программистов (источник), которое показало что соотношение лучших и худших программистов составило:
Эти цифры в разных вариациях уже все видели. А вот тот факт, что исследование проводилось на программистах, имевших в среднем 7 лет опыта разработки с небольшими отклонениями, не знает никто.
Аналогичные исследования повторялись другими группами ученых на протяжении 30 лет:
Они также показали разницу между худшими и лучшими в разы (хотя конечно меньше чем в 25 раз). И также не показали никакой связи между продуктивностью и опытом работы.
С 1968 года в разработке улучшилось буквально все: языки, фреймворки, инструменты, а также программированию теперь обучают несколько лет в вузе. Тем не менее продуктивность программистов как отличалась в разы 30 лет назад, так и отличается сегодня.
Это наводит на мысль, что есть некоторый икс-фактор, не связанный с опытом, который отличает хорошего программиста от плохого. На сегодняшний момент нет единого мнения что это за фактор. Одни говорят что это умение планировать свою работу и “видеть” структуру кода еще до того, как код написан. Другие говорят, что самые продуктивные программисты те, кто умеет быстро выдавать видимый результат. Мои личные наблюдения говорят о том, что лучше всего пишут код те, кто умеет читать код.
Если отбросить этическую сторону вопроса, то надо уволить всех низко продуктивных программистов, невзирая на опыт. Серьезно, учитывая факты выше, можно набрать небольшую команду относительно недорогих, но высоко продуктивных, программистов. И это будет в разы выгоднее чем держать штат опытных специалистов.
Еще один вывод, который немного противоречит логике, но часто встречается на практике: программист не станет более продуктивным, получив годы опыта. Единственный способ улучшить продуктивность и качество кода программистов – проводить целенаправленное обучение и тренировку.
Последнее, но не менее важное — надо сильно пересмотреть методику найма программистов. Вместо отсева по ключевым словам в резюме и задач на логику, надо кандидатам писать код, желательно в “лабораторных” условиях, чтобы можно было отследить продуктивность и качество.
Надо понимать что продуктивность совсем не тоже самое, что эффективность. В современном мире, где сложность технологий растет быстрее, чем люди успевают технологии изучать, где у любой проблемы гораздо больше одного решения, где большая часть кода уже написана, на первый план выходит не продуктивность программиста, а умение находить и комбинировать готовые решения, а также умение придумать нестандартное решение. Но чем больше проект, тем более важны продуктивность и качество кода, и, тем более, важны подбор и обучение команды.
В 1968 году было проведено исследование продуктивности работы программистов (источник), которое показало что соотношение лучших и худших программистов составило:
- 20:1 по времени написания кода
- 25:1 по времени отладки кода
- 10:1 по скорости работы программы
- 5:1 по объему кода
Эти цифры в разных вариациях уже все видели. А вот тот факт, что исследование проводилось на программистах, имевших в среднем 7 лет опыта разработки с небольшими отклонениями, не знает никто.
Но это было давно и в исследовании куча ошибок...
Аналогичные исследования повторялись другими группами ученых на протяжении 30 лет:
Список исследований
- Curtis, Bill. 1981. «Substantiating Programmer Variability.» Proceedings of the IEEE 69, no. 7: 846.
- Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.
- DeMarco, Tom, and Timothy Lister. 1985. «Programmer Performance and the Effects of the Workplace.» Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.
- Curtis, Bill, et al. 1986. «Software Psychology: The Need for an Interdisciplinary Program.» Proceedings of the IEEE 74, no. 8: 1092-1106.
- Card, David N. 1987. «A Software Technology Evaluation Program.» Information and Software Technology 29, no. 6 (July/August): 291-300.
- Boehm, Barry W., and Philip N. Papaccio. 1988. «Understanding and Controlling Software Costs.» IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.
- Valett, J., and F. E. McGarry. 1989. «A Summary of Software Measurement Experiences in the Software Engineering Laboratory.» Journal of Systems and Software 9, no. 2 (February): 137-48.
- Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.
Они также показали разницу между худшими и лучшими в разы (хотя конечно меньше чем в 25 раз). И также не показали никакой связи между продуктивностью и опытом работы.
Что это значит?
С 1968 года в разработке улучшилось буквально все: языки, фреймворки, инструменты, а также программированию теперь обучают несколько лет в вузе. Тем не менее продуктивность программистов как отличалась в разы 30 лет назад, так и отличается сегодня.
Это наводит на мысль, что есть некоторый икс-фактор, не связанный с опытом, который отличает хорошего программиста от плохого. На сегодняшний момент нет единого мнения что это за фактор. Одни говорят что это умение планировать свою работу и “видеть” структуру кода еще до того, как код написан. Другие говорят, что самые продуктивные программисты те, кто умеет быстро выдавать видимый результат. Мои личные наблюдения говорят о том, что лучше всего пишут код те, кто умеет читать код.
И что теперь делать?
Если отбросить этическую сторону вопроса, то надо уволить всех низко продуктивных программистов, невзирая на опыт. Серьезно, учитывая факты выше, можно набрать небольшую команду относительно недорогих, но высоко продуктивных, программистов. И это будет в разы выгоднее чем держать штат опытных специалистов.
Еще один вывод, который немного противоречит логике, но часто встречается на практике: программист не станет более продуктивным, получив годы опыта. Единственный способ улучшить продуктивность и качество кода программистов – проводить целенаправленное обучение и тренировку.
Последнее, но не менее важное — надо сильно пересмотреть методику найма программистов. Вместо отсева по ключевым словам в резюме и задач на логику, надо кандидатам писать код, желательно в “лабораторных” условиях, чтобы можно было отследить продуктивность и качество.
Заключение
Надо понимать что продуктивность совсем не тоже самое, что эффективность. В современном мире, где сложность технологий растет быстрее, чем люди успевают технологии изучать, где у любой проблемы гораздо больше одного решения, где большая часть кода уже написана, на первый план выходит не продуктивность программиста, а умение находить и комбинировать готовые решения, а также умение придумать нестандартное решение. Но чем больше проект, тем более важны продуктивность и качество кода, и, тем более, важны подбор и обучение команды.
