Как менеджеры выбирают языки программирования

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

Будучи самим программистом, я никогда не мог этого понять.

Но теперь я думаю, что знаю: у меня только что было откровение, когда Джоэл Спольски сказал на подкасте, что им следует использовать QuickBooks, потому что «это знает каждый бухгалтер в мире». Это показалось мне очень похожим на «выбрал Java, потому что каждый программист в мире знает это».

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

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

Это выходит за рамки выбора языка программирования и пронизывает практически каждое техническое решение.

Позвольте привести пример: ПК. Джоэл утверждает (правильно), что у разработчиков должны быть первоклассные машины, потому что время разработки дорого. В этом он совершенно прав. Но как вы спорите об этом? Просто:

Пример: я делаю сборку кода примерно 20 раз в день. Каждый раз это занимает 3 минуты. Если бы у меня был быстрый ПК, я мог бы собрать его за 1,5 минуты. Таким образом, за дополнительные 1000 долларов каждые два года я могу получать дополнительные полчаса в день, что для программиста, зарабатывающего 100 тысяч долларов (с затратами минимум на 50%), что равняется примерно 10000 долларов в год.

Но на другом конце спор о том, что HR решает, что один размер подходит всем, когда речь заходит о политике и ПК, поэтому работник колл-центра зарабатывает 25 тысяч долларов, а программист зарабатывает четыре раза, которые по какой-то причине должны иметь один и тот же компьютер.

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

• Стратегические отношения с конкретными поставщиками. Если ваша компания является Золотым партнером Microsoft (или как она там сейчас называется), тогда желаю вам присоединиться к Java или Python;
• ИТ-отдел обсуждает конкретную конфигурацию, потому что деньги на ПК идут из их бюджета;
• ИТ-специалисты решают, что все должны использовать Windows 2000, потому что у них нет людей, работающих под Linux;
• Какие другие системы у компании уже есть (например, если они используют Java для всего остального, имеет смысл использовать его для этого, хотя сам по себе это может быть не лучшим выбором);
• Неприятие риска к различным платформам или языкам просто из-за недостатка опыта;
• Больше интересует обсуждение риска с высшим руководством, чем радует разработчиков;
• Некоторые менеджеры принимают решения, которые они принимают просто потому, что их руки связаны;
• Бюджетные причины, хотя это может сработать и в вашу пользу, так как не позволяет дорогим защитным очкам выходить из дома, например, PVCS, всему, что производится Rational и т. Д .;
• Отклонение юридического отдела к лицензиям с открытым исходным кодом;
• Не привлекать технический персонал к планированию и оценке проекта;
• Знакомство менеджера со специфической платформой (в этом тоже виноваты технические специалисты, но в обоих случаях это не обязательно плохо - со многими инструментами, которые могут сделать работу лучше, черт возьми, вы знаете).
• Опыт технического персонала. Если они все из C # фона, почему они используют Java, Python или Ruby?
• Много других причин

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

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

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

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

Как менеджеры выбирают языки программирования?

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

• политическая
  • «Никто не был уволен за покупку IBM» - безопасный выбор.
  • Генеральный директор слышал, что Java это круто - ажиотаж.
  • Главный архитектор любит .NET - любимый проект.
  • Язык контролируется враждебным конкурентом - почему Google не полагается на C #.
• экономный
  • Лицензионные расходы.
  • Стоимость обучения разработчиков.
  • Затраты на перенос базы кода.
• Социальное
  • Бай-ин от команды.
  • Наличие навыков в доме (потребности в обучении, преемственность).
  • Наличие навыков на рынке.
  • Угроза существующему статус-кво в команде разработчиков.
  • Наличие достаточно большого сообщества практиков.
• технологический
  • Улучшение производительности.
  • Улучшение качества.
  • Возможность взаимодействия с существующей кодовой базой.
  • Соблюдение стандартов.
  • Зрелость.
• легальный
  • Условия лицензирования.
  • Технологический контроль (Кто владеет технологией и контролирует ее? Какова будет стратегия лицензирования в будущем?)
  • Соблюдение правовых и нормативных требований
• экологическая
  • Существующая инфраструктура внутри компании.
  • Существующие навыки внутри компании.
  • Интеграция с внешними партнерами.
  • Уровень технологической поддержки более широкой средой.

Затем группа языков, соответствующих критериям, может быть дополнительно оценена с использованием SWOT , анализа затрат и результатов или подобного.

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

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

Как мы надеемся, было продемонстрировано, что обычный программист обычно получает лишь 1/6 от общего вклада в процесс принятия решений. И, как правило, ее или ее больше всего интересуют только языковые возможности!

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

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

1. Текущая платформа больше не является адекватной.
2. Новая платформа обещает преимущества, которые намного перевешивают трудности.

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

Менеджер А отправляется на летнее отступление, где встречает менеджера Б.

A: Так какой язык вы используете в своей компании? B: О, мы используем CA Visual Objects, это делает дроны намного более производительными, чем COBOL.

И так было принято решение. Конец правдивой истории.

У каждой платформы есть хорошие и плохие стороны. .NET круто и мощно, но вы в значительной степени застряли на серверах Windows. Руби это круто, но медленно. Было бы трудно найти разработчиков для Haskell.

Дело в том, что язык влияет не только на то, как быстро будет выполнен проект и насколько красивым будет код, но и на тех, кто заботится о менеджерах. Так что, если вы хотите повлиять на них, вы должны теперь их предпочтения и найти как можно больше хороших сторон в их перспективе.

Разделяя проблемы. Бизнес должен отвечать за деловые решения, а технологии - за технические решения. Мне нравится термин «Принятая ответственность». Если я принимаю ответственность, я также требую, чтобы я сделал выбор, который касается моей области проблемы. Бизнес дает мне и моим коллегам по технологиям требования бизнеса, и мы отвечаем одним или двумя вариантами того, как мы можем принять на себя ответственность за поставку. Это никогда не должно быть похоже на «мы сделаем это на Python или C #». Скорее;

«Мы можем взять на себя две разные обязанности: если мы пойдем по этому пути, мы сможем выполнить это быстро, и мы действительно хорошо отвечаем этим бизнес-требованиям, и это немного сложнее. Мы также могли бы сделать это таким образом, что дает этим бизнес-требованиям преимущество». Альтернатива A требует этих ресурсов, а альтернатива B означает, что мы должны сделать то же самое и это ... »

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

Станьте менеджером. (Гринь)

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

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

Это очень сильно зависит от личности менеджера:

Есть те, которые идут на модные слова. Просто узнайте, какие модные слова им нравятся, и используйте их, когда говорите с ним в сочетании с языком, который вы хотите использовать.

Другие будут доверять только тем вещам, которые они сами знают (например, VB 6.0). Сделайте ваш язык понятным для них («вы знаете, это так же, как в старом добром VB» - даже если вы говорите о Haskell ...)

Но на самом деле большинство менеджеров не так глупы, как нам нравится думать, и их можно аргументировать. Здесь важно то, что вы понимаете их точку зрения: они обычно не заботятся о конкретных технических деталях, они заботятся о результатах. Так что не говорите им, что .net, Java или Delphi, или что-то еще, обладают потрясающей функцией megacool Скажите им, что (введите ваш язык здесь) - хороший выбор, потому что функция A позволяет сократить время разработки в подобном проекте, или эта функция B уменьшает количество ошибок и, следовательно, сокращает время, необходимое для тестирования. Просто убедитесь, что ваш аргумент обоснован, не лгите ему.

Другими словами: относитесь к нему как к разумному существу (он, вероятно, есть).

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

Выбор языка программирования часто является бизнес-решением. Клиенты / пользователи не заботятся. Вот короткая цитата (с http://www.ericsink.com/bos/Geeks_Rule.html ):

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

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

Сколько сил и время это стоили бы Рембрандта дополнительной не рисовать его любимую кисть, а кисть , что после тщательного изучения команды управления, передаются ему, 400 лет назад , и до его работ становится известной. Будет ли его картина более или менее стоит думать?

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

Это разные понятия.

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

При программировании вы используете любой инструмент, который вам нужен - до тех пор, пока он выводит .exeфайл, который вы можете запустить в Windows. Это в точности то же самое, что читаемый документ Quick Books в случае бухгалтерского учета.

Итак, если вы разрабатываете тостер, вы можете хранить свою внутреннюю документацию на китайском языке, но вам лучше предоставить руководство на английском языке.

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

То, что они выбирают, зависит от их целей: если они хотят легко заменяемых программистов, они выбирают Java; если они отправят его в другой отдел, это будет требованием этого отдела и т. д.

По моему опыту это всегда зависело от:

1. Есть ли у нас ресурсы для использования языка?
2. Есть ли у нас ресурсы для поддержания языка?
3. Если у нас нет ресурсов для использования и поддержания языка, насколько сложно / дорого получить эти ресурсы?
4. Каково «будущее» языка (оно будет некоторое время использоваться и использоваться?)

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

Надеюсь, у вас есть программист, который также является менеджером и может представлять программистов в таких решениях. Если нет, то это опасная ситуация, и вам следует поговорить с вашим менеджером, если вы знаете, что такое решение принимается.