Каковы худшие ложные экономики в разработке программного обеспечения? [закрыто]

126

Какие наихудшие ложные экономики (то есть способы экономии денег, которые в конечном итоге стоят больше, чем они экономят) преобладают в индустрии программного обеспечения и как с ними бороться?

programming-practices project-management

— Джон Хопкинс
источник

2

:( Я видел много таких слишком часто.

— Тони

3

Похожие программисты.stackexchange.com

— questions/18585/…

@Casey: Это немного связано, но не совсем. Ссылка, которую вы дали, касается непосредственно денег, а ответы на этот вопрос здесь также касаются денег и убеждений. Пример, см. Мой ответ: programmers.stackexchange.com/questions/19573/…

— Ган

Вы только что посетили мою компанию ... не обращайте внимания; P

— pramodc84

1

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

— Джон Хопкинс

182

Технический долг

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

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

— оборота Инамати
источник

2

Я не могу сосчитать, сколько раз я видел, как менеджеры останавливали разработчиков (от 2 до 3) в течение дня, а затем специалиста по развертыванию, чтобы что-то исправить (и делать это много раз в течение жизненного цикла продукта) вместо того, чтобы тратить 2- 4 дня, чтобы сделать это правильно. Отличный ответ.

— DevSolo

4

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

— Дж.Б. Уилкинсон

9

У нас есть весь код с комментариями типа «Это хак, замени после демоверсии», который был в базе на протяжении 3-5 лет. Никто даже не помнит, что это было сделано в этот момент, поэтому никто не находит его, пока кто-то (я) не исправит ошибки и не наткнется на него. Излишне говорить, что этот предметный урок очень хорошо научил меня делать это правильно с первого раза, если я каким-либо образом могу это сделать.

— CodexArcanum

22

И, честно говоря, я постоянно шокирован тем, сколько раз это не спасает даже короткое время!

— PeterAllenWebb

6

@Jorg - А? «Технический долг и долг за дизайн - это синонимы, неологистические метафоры, относящиеся к возможным последствиям архитектуры программного обеспечения slapdash и поспешной разработки программного обеспечения». en.wikipedia.org/wiki/Technical_debt Это именно то, что я имею в виду. Более конкретный заголовок, возможно, был бы «Возникновение технического долга без намерения его погасить», но многие люди в этой ситуации говорят себе, что они на самом деле намереваются погасить (но не делают), и я хотел, чтобы в него вставили резкое название. жирный текст вверху. «Техническая задолженность» казалась достаточно хорошим резюме.

— Инамати

163

Наем 2 дешевых разработчиков вместо 1 действительно здорово. (по той же цене)

— user2567
источник

9

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

— Инамати

112

Или, к сожалению, просто нанять 1 дешевый ...

— DevSolo

4

... или нанять гуру, где два манекена выполнили бы 1,5 того, что гуру делает за 1,0 зарплаты гуру: /

— bobah

14

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

— Питер Боутон

8

Программисты в 10 или 100 раз - это невероятно невероятное соотношение цены и качества; им платят только 1,5, может быть, 2 раза. Как говорит Майкл Лопп (Rands in Repose), если вы наняли одного из них за всю свою карьеру, это чистая победа.

— Тим Уиллискрофт

85

Мой пример будет полной противоположностью примеру НимЧимпски , а именно:

Попытка разработать что-то собственное, что можно купить в продаже.

Обычно это происходит из-за неспособности фактически проверить рынок, чтобы увидеть, существует ли уже что-то, что решит проблему. Это может быть усугублено разработчиками, которым нравится «погружаться» в кодирование, прежде чем проводить какие-либо исследования, и менеджерами проектов, которые не учитывают в это время = деньги.

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

— Дан Диплом
источник

17

То, что это может быть, не значит, что так должно быть. Базовая CMS, ну да, зачем изобретать велосипед. Но когда вы начинаете говорить о крупномасштабных системах и моделировании сложных бизнес-процессов - зачем пытаться втиснуть круглый стержень в квадратное отверстие? Особенно, если у вас есть разработчики и навыки в доме.

— НимЧимпский

9

@NimChimpsky - я думаю, что есть действительные примеры обоих. Я, конечно, видел, как люди ломали свои бизнес-процессы и теряли преимущества, которые они имели, пытаясь приспособить их к готовому программному обеспечению, но я также видел разработчиков, страдающих от «не изобретенного здесь» кода, который они могли бы просто загрузить, потому что им было интереснее.

— Джон Хопкинс

3

@NimChimpsky Если спецификация требует разработки на заказ, то это нормально - она удерживает нас в работе :) Проблема возникает, когда люди сначала не проверяют, есть ли уже что-то разработанное, отвечающее всем требованиям, и сразу погружаются в разработку. Небольшое исследование может иметь большое значение!

— Дан Диплом

6

Зачем изобретать велосипед? Потому что ты инженер по колесам. Или потому что ваше колесо лучше, чем колесо следующего парня. Или потому что колесо не подходит. Смотрите: преимущественноmaths.net/2010/03/…

— Дерек

2

Там, где я работаю, почти все можно купить OTS - и почти все заново изобретается, потому что, по словам наших бесстрашных лидеров (tm), «наша среда настолько сложна, что на рынке ничего не может с этим поделать ». Pfeh! Но что за эй - это оплачивает счета. Вчера нам сообщили, что основной компонент нашего программного обеспечения будет переписан в следующем году - С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ! Ooooooh-aaaaaaah! Я все в твиттере ... (<pheh!>)

— Боб Джарвис

73

Нет выделенных ресурсов для управления проектами

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

Плохое оборудование для новых программистов

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

— user281377
источник

19

+1. Недостаточно хорошее оборудование для ваших сотрудников означает «обречено на провал».

— Теренс Понсе

3

+1. Но обратите внимание на следующее: во многих компаниях аппаратные бюджеты подпадают под инфраструктуру и отделены от бюджетов разработки. Менеджер по инфраструктуре не собирается наносить удар по своему бюджету, чтобы помочь облегчить бюджет менеджера по развитию. Я видел, как эта неприятная политика играла несколько раз.

— Fil

3

Как насчет плохого оборудования для ВСЕХ программистов? Мой бывший работодатель платил нам зарплату в Силиконовой долине за написание кода для настольных компьютеров, который был посредственным пять лет назад. Из-за сжатых сроков они уволили половину персонала год назад, а большую часть - в июле - но, ребята, они сэкономили деньги на оборудовании!

— Боб Мерфи

1

Kaz: Каждый разработчик должен иметь адекватную машину. Если покупка нового оборудования означает, что ПК нового разработчика немного лучше, чем у других разработчиков, то в худшем случае у вас есть своп-машины, если они люди, которые любят размер члена. Нормальным людям будет все равно, если у них есть оборудование, которое позволяет им работать эффективно. В том месте, где я сейчас работаю, у меня более новый (возможно, более быстрый) компьютер, чем тот, кто меня нанял. Люди, которые пришли за мной, имеют еще более новые, возможно, более быстрые компьютеры. Угадай, что? Никому нет дела, потому что все наши машины достаточно быстрые.

— user281377

3

Когда аппаратное обеспечение неадекватно, я хочу сообщить об этом руководству, обычно выполняя полезную работу, например стриг ногти на ногах или читая газету во время длинных компиляций. Я получаю старую медленную машину? Конечно, нет проблем. О, у вас есть срочная ошибка, и я должен сделать сборку? Конечно, мистер-менеджер-bwana-sahib-чувак - увидимся через 90 минут! (Однажды один менеджер спросил меня, что я делал весь день - я сказал ему: «Пересобрал приложение. Четыре раза». «ВОСЕМЬ ЧАСОВ?!?» - воскликнул он. «Нет, конечно, нет», - сказал я ». Это заняло 10 часов ". Новая машина появилась вскоре после ... :-)

— Боб Джарвис

71

Мы можем сэкономить деньги, если программисты выступают в роли тестировщиков / технических писателей.

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

Кстати: разработчики ВСЕГДА находятся в сжатые сроки.

— оборота JohnFx
источник

12

Умные люди могут делать все, что угодно.

— Джон Хопкинс

3

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

— Дэвид Торнли

1

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

— Бен Лэйки

3

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

— JohnFx

1

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

— Адам Брусс

63

Исследование / Чтение / Написание кода, не связанного с разработкой продукта, является пустой тратой ресурсов.

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

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

— Ган
источник

3

Хотел бы я проголосовать за это не раз.

— MAK

1

Давайте напишем библиотеку GUI. Давайте создадим набор инструментов для обмена сообщениями. Если вы не ПРОДАЕТЕ часть программного обеспечения, это только часть более масштабной вещи, ради всего святого, просто используйте чью-либо реализацию. Точки безопасности при использовании решения с открытым исходным кодом, вы всегда можете исправить и поддержать его, если потребуется. Если у вас есть деньги на покупку решений с включенным источником, сделайте это, но остерегайтесь низкого качества коммерческих компонентов программного обеспечения. Продавцы редко продают вам компонент дважды, так что вы можете быть разочарованы, если вы им владеете (я знаю, что работал в местах, которые укусили это раньше)

— Тим Виллискрофт

58

Во многих случаях офшоринг стоит больше денег. В моей компании очень сложно получить новые слоты для сотрудников, нас сильно подталкивают к аутсорсингу. Также трудно найти подрядчиков на месте; есть соотношение 3: 1 на суше и на суше, которое они должны поддерживать. Следовательно, многие команды просто нанимают дюжину оффшоров и почти не используют их, просто чтобы получить 4 подрядчиков на месте.

— Джереми
источник

18

+1. Мой опыт работы с оффшорингом заключается в том, что он неизбежно стоит гораздо больше денег, чем экономит.

— Адам Кроссленд

2

+1, но оффшор может работать при правильном использовании

3

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

— Крис Найт

8

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

— пул

1

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

— HLGEM

50

Длинные петли обратной связи!

Это случается со всеми: вы создаете что-то, что вы считаете удивительным, и получается, что вы ошиблись. Это не проблема. Проблема в том, как долго вы проводите строительство, прежде чем узнаете, что вам следует остановиться.

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

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

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

— Уильям Пьетри
источник

6

+1. Также: чем дольше цикл обратной связи, тем меньше вы помните о задаче. В крайнем случае, вам нужно заново знакомиться со всей базой кода заново.

— Джозеф Таненбаум

Как это ложная экономика? Какова предполагаемая экономия?

— Крис Питман

Цель состоит в том, чтобы сэкономить время, потраченное впустую на то, что вы делаете в каждом цикле. Например, сборка, тестирование, выпуск, уделение внимания пользователям. Во всяком случае, это оправдание. Я думаю, что это действительно коренится во избежание дискомфорта.

— Уильям Пьетри

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

— Джонатан Нойфельд

47

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

В значительной степени определение ложной экономики.

— EricBoersma
источник

4

Это довольно особенное. Сравните и сопоставьте это с некоторыми коммерческими банками в Лондоне, которые построили субсидируемые Starbucks в здании, чтобы сократить время, необходимое для того, чтобы выйти и получить кофе.

— Джон Хопкинс

48

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

— JBRWilkinson

6

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

— Малфист

23

@Malfist: Насколько я понял, это была не только 20-минутная прогулка, но и 15-минутное ожидание, чтобы получить кофе, который прервал работу. 45-минутный перерыв в любой точке дня в значительной степени приведет к снижению производительности на более чем полтора часа. Все, чтобы сэкономить 100 долларов в месяц на кофе.

— EricBoersma

8

20 + 15 = 35 [еще шесть символов]

— Малфист

47

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

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

Настройки нескольких мониторов:

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

— Арьен Круитхоф
источник

2

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

— Раффаэль

39

Самое дешевое оборудование предоставляется консультанту при стоимости консультанта более 150 $ / час .

Если рассматривать это в перспективе, то лучшее оборудование может повысить эффективность работы на 30 минут в день. Это дало бы 30 минут * 20 дней работы в месяц = 600 минут / месяц = 10 часов / месяц> больше, чем 1 день работы = 10 часов * 150 $ / час = 1500 $

Разве консультант не работал бы более эффективно, если бы у него был компьютер за 1500 $? Это сделает консультанта менее раздраженным?

Теперь проблема заключается в том, что существует два бюджета, один для консультанта и один для аппаратного обеспечения ПК.

— Амир Резаи
источник

8

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

— Боб Мерфи

2

Без обид, но если я плачу 150 долларов в час за консультанта, ему лучше иметь свой компьютер.

— Стивен Эверс

8

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

— HardCode

1

@ HardCode - Да, я полагаю. Теперь я вижу смысл.

— Стивен Эверс

3

@HardCode В недавнем проекте вместо того, чтобы добавить нас (подрядчиков) в свою внутреннюю корпоративную сеть, они изолировали нас от нашей собственной линии DSL. Выделенная линия DSL для 3 разработчиков по цене 40 долларов в месяц - это смена чепухи, и нам было легко отправлять обновления удаленно, не пугая ИТ-специалистов. Кроме того, если производственный ПК, на котором работает наш код, заражается и вылетает, это автоматически является нашей ошибкой, поскольку мы несем ответственность за безопасность наших коммуникаций и персональных ноутбуков. Можете ли вы сказать беспроигрышный.

— Эван Плейс,

38

Месяцы работы экономят дни планирования

(Не вкладывая достаточно времени в планирование)

— Serg
источник

21

В аспирантуре говорилось, что несколько недель в лаборатории могут сэкономить вам час библиотечного времени.

— Дэвид Торнли

7

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

— Боб Мерфи

3

Если вы не в состоянии планировать, вы планируете потерпеть неудачу

27

Я подозреваю, что наиболее распространенными являются менеджеры, которые просто не предоставляют разработчикам инструменты, необходимые им для эффективной работы.

В основном, пункт 9 на тесте Джоэла .

— richeym
источник

2

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

— MetalMikester

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

— Кен Хендерсон

24

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

— JB King
источник

2

+1. О боже да В настоящее время это происходит в эпическом масштабе в крупном проекте, где я работаю.

— Бобби Столы

3

Я работаю с кучкой руководителей проектов, менеджеров и т. Д., Каждый из которых имеет свою замечательную сертификацию управления проектами (какого бы черта это ни называлось), и НИ ОДИН из них не слышал о «Мифическом человеко-месяце» до того, как я представил их к этому. Sheesh!

— Боб Джарвис

2

Однажды я услышал замечательную цитату об этом: 9 женщин не могут родить ребенка в месяц

— Ричард

@Richard Я использовал это на собрании. доставил мне огромное удовольствие!

— Tjaart

21

Ежедневные встречи :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...

— Zzz
источник

9

Встреча только ради встречи ...

— Ган

5

Повестка дня на сегодня: что будет в повестке дня завтрашнего заседания?

— Марк С

9

Ежедневные встречи хороши, если они короткие; Трехминутные фуршеты в стиле Scrum не теряют много времени, но держат всех в курсе событий всех остальных. Зато долгие встречи с многочисленными незаинтересованными участниками ядовиты.

— 9000

3

@Mark C - Это может звучать как шутка, но на самом деле меня приглашали на собрания, чтобы спланировать повестку дня следующей встречи ...

— Гэвин Коутс

@ Гэвин Коутс, это реально и ситуация ... :)

— Zzz

20

Покупка готового программного обеспечения вместо внутренней разработки.

У меня есть опыт систем управления масштабами предприятия, ориентированных как на HR, так и на биологические лаборатории.

Готовое решение стоило £ 50-100 тыс. И нуждалось в дальнейшей разработке и настройке в соответствии с требованиями бизнеса.

Для разработки внутреннего решения потребовалось (<6) месяцев, параллельно с другими проектами, и использовался уже нанятый разработчик.

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

(6 месяцев уже нанятого разработчика, работающего над другими проектами параллельно. Так что ~ 10 тыс. И это не включает расходы на поддержку, связанные с готовым решением). Суть в том, что внутренне разработанная система фактически использовалась! Таким образом, у вас есть дополнительная экономическая выгода, связанная с этим, которую я не могу рассчитать.

Я согласен на базовые веб-сайты и т. Д., Зачем создавать свои собственные. Но для любых больших сложных систем, и если у вас уже есть домашние навыки, я бы сам их создал .

— оборота НимЧимпский
источник

26

Бьюсь об заклад, есть множество примеров противоположного тоже.

— Джон Хопкинс

13

Покупать или развивать зависит от правильных людей, которые проводят тщательную проверку. Просто как тот. Думай прежде чем сделать. (+1)

— DevSolo

4

@DevSolo: на месте. Решение о покупке или покупке должно быть подкреплено анализом затрат и выгод, а не эмоциональным отношением «не изобретено здесь» или «Я люблю программное обеспечение XXX».

— JBRWilkinson

9

Если вы собираетесь сделать общее заявление о сборке против покупки, это должно быть: предпочитайте покупать решения проблем, которые не являются частью основной компетенции вашей компании. Это не всегда правильный ответ, но это разумная позиция по умолчанию, и она настолько надежна, насколько может быть клише. Сказать, что покупка готового программного обеспечения - ложная экономия, однако, даже не является полезным клише. Я чувствую вашу боль по отношению к решениям «E» (что должно означать «Enterprise», но на самом деле означает «Дорогой» «). Но наличие плохих вариантов не означает, что там нет хороших.

— evadeflow

2

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

— Ян

15

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

Сколько компаний используют git? Сколько компаний используют какой-то дерьмовый корпоративный контроль версий?

— Hasen
источник

1

Хм, это можно считать "худшей ложной экономикой"? Или, возможно, вам нужно уточнить подробнее ...?

— Ган

3

Я не уверен, что полностью согласен с примером контроля версий, по крайней мере. Git был специально разработан для решения проблем с открытым исходным кодом: многие разработчики, мало централизованного управления, много филиалов и т. Д. «Корпоративное» программное обеспечение работает в соответствии с другим набором предположений: необходимость управлять различными продуктами в рамках бизнеса, безопасность, рабочий процесс и т. д.

— PeterAllenWebb

1

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

— Хазен

3

Я работаю над X11 и GNOME и достаточно компетентен в использовании git и администрировании серверов gitosis. Тем не менее, этим летом я переключил свою консалтинговую работу с git на лично оплачиваемый сервер Perforce, потому что он автоматически делает много вещей, которые вы должны делать вручную с помощью git. Поскольку мне платят за доставку кода, а не за контроль над версиями, использование и оплата «дрянного контроля версий предприятия» гораздо более рентабельны, чем использование git.

— Боб Мерфи

7

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

— MetalMikester

14

Использование «простых» языков без особой выразительности

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

— dsimcha
источник

4

@burnt_hand: Я в основном имею в виду чрезмерное неприятие риска со стороны руководства с точки зрения выбора языка.

— дсимча

1

+1: просто продолжайте использовать C, потому что «у нас есть эти навыки, и изучение какого-то нового необычного языка, такого как Python / Perl / PHP, увеличивает риск». Слышал это не раз. Значит ли это, что команда слишком глупа, чтобы изучать новый язык?

— S.Lott

1

@ S.Lott Рекрутинговые агенты думают, что ты !, но это другая история

— burnt_hand

2

то есть компании, которые придерживаются Java и C # и слишком боятся трогать python или ruby, потому что они не являются «отраслевым стандартом», что напоминает мне: paulgraham.com/avg.html

— hasen

1

@hansen: эссе Пола Грэма частично вдохновило меня на написание этого поста. Мое другое вдохновение было моей работой по разработке библиотек (включая стандартную библиотеку) для языка программирования D.

— дсимча

13

Плохие руководители проектов / руководитель группы.

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

Доза "Просто сделай это быстро, мы рефакторинг позже" решает.

— Амир Резаи
источник

4

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

— Джон Хопкинс

2

@ Джон Хопкинс С высшим руководством я не отсылаю клиентов. Дело в том, что «плохие менеджеры проектов» - это те, кто делает ошибки за ошибками и идет против группы людей. Как вы думаете, кто решит: «Просто сделайте это быстро, мы проведем рефакторинг позже». Прочитайте ответ с наибольшей скоростью!

— Амир Резаи

ах, понятнее. Я удаляю свой -1.

— Джон Хопкинс

Я заметил тревожную тенденцию менеджеров проектов обращать время и затраты на качество. Я уверен, что я не единственный. Премьер-министры любят использовать треугольную диаграмму с надписью «Цена / качество / время», но качество всегда загружается первым. Это очень печально, и институционализация и принуждение к метрикам управления проектами (PMI) для чего-то столь сложного, как программное обеспечение, только ухудшает ситуацию.

— Бернард Ди

1

@ Бернард - время и стоимость измеримы. Качество? Не так много. Грустно, но ИМО правда ...

— Боб Джарвис

12

Отсутствующие требования пользователя

Важным и сложным этапом разработки программного продукта является определение того, что клиент на самом деле хочет от него.

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

— Амир Резаи
источник

Я думаю, что это должно быть на вершине!

— Рупеш Шеной

8

Производительность стоит больше, чем творчество

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

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

— blueberryfields
источник

6

Все ниже может быть плохо, если используется или не используется ненадлежащим образом

внешнее и внутреннее программное обеспечение
Соответствие ISO 9001 (экономия - снижение риска потери MSS, если качество продукта падает)
разработка / QA аутсорсинг
процедуры разработки / сборки / выпуска / поддержки

— оборота боба
источник

Как ISO 9001 является (ложной) «экономией»?

— Эндрю Гримм

@ Эндрю Гримм - соответствие обеспечивает определенный уровень качества, который снижает риски, связанные с низким качеством (например, потеря MSS), поэтому потенциальная экономия очевидна. Для небольших отделов это может быть неуместно, потому что потери на накладные расходы выше, чем потери от потенциального риска

— бобах

1

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

— Джон Хопкинс

5

@ Эндрю Гримм - «Единственное», что гарантирует ISO 9001 - это стабильное, воспроизводимое качество. Это не гарантирует «высокое» качество. Однако, если квалификация ISO 9001 - это то, что требуется в рыночном пространстве, в котором компания хочет быть, то это необходимо.

— Vatine

1

@Vatine: то, что ISO 9001 гарантирует, является последовательным, повторяемым процессом. В некоторых областях, где согласованные процессы дают стабильное качество, это важно. Это не гарантирует высокое качество, но если покупатель увидит, что вы хорошо поработали, и знает, что вы сертифицированы по ISO 9001, он будет уверен в аналогичном качестве.

— Дэвид Торнли

4

Слишком много неоплачиваемых менеджеров по доставке.

Пару лет назад в нашей компании было несколько крупных бюджетных проектов, и набор был на пике. В то время наша компания наняла слишком много менеджеров по доставке (многие из них не были ИТ-специалистами!) И очень мало программистов / тестировщиков. Соотношение менеджера и программиста было буквально 1: 2. Позже, после завершения этих проектов, у нас была ситуация, когда многие из этих менеджеров (некоторые из них были настоящими бездельниками) сидели на скамейке и ничего не делали. У нас был один цикл оценки, когда у всех было мало / нет повышения (даже мы, трудолюбивые программисты, вздох), чтобы компании не пришлось никого увольнять! К счастью, компания осознала эту ситуацию и сделала RIGHTSIZING в первом квартале этого года!

— mananjani
источник

3

Оптимизация перед профилированием (преждевременная оптимизация).

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

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

— Эдвин Бак
источник

3

Ограниченный или нет доступа в интернет

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

В действительности, конечно, Интернет является огромным приростом производительности, и, хотя может быть целесообразно использовать какой-то фильтр сайтов для действительно изворотливых сайтов, есть какая-то ошибка, если он блокирует файл readme для Visual Studio или блокирует страницы местного правительства Телфорда по причине "секс туризм"

— JK.
источник

2

Заставить ваших разработчиков использовать 15-дюймовый монитор и ПК низкой спецификации, так как это корпоративный стандарт.

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

— Ян
источник

2

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

— Инго
источник