Comments 23
2 пинты молока стоят 85 пенсов, или 42,5 пенса за пинту (стоимость одной пинты — 36 пенсов).
Видимо, в скобочках должны быть литры.
Нет, пенсы. Но тут требуется пояснение. В оригинале используется термин marginal cost, что может переводиться как «предельные издержки» на производство дополнительной единицы продукции (см. ru.wikipedia.org/wiki/Предельные_издержки).
Т.е. если 1 пинта стоит 49 пенсов, а 2 пинты стоят 85 пенсов, то получается что во втором случае вы как бы покупаете первую пинту за 49, а вторую пинту уже за 36 пенсов. Поэтому автори и пишет, что marginal cost второй пинты = 36 пенсов. Ну и аналогично с 4 пинтами.
Подправил в тексте немного, чтобы было понятнее.
Т.е. если 1 пинта стоит 49 пенсов, а 2 пинты стоят 85 пенсов, то получается что во втором случае вы как бы покупаете первую пинту за 49, а вторую пинту уже за 36 пенсов. Поэтому автори и пишет, что marginal cost второй пинты = 36 пенсов. Ну и аналогично с 4 пинтами.
Подправил в тексте немного, чтобы было понятнее.
В производстве ПО "нет экономии на масштабе" потому что в большинстве случаев отсутствует сам масштаб
Программа единичное уникальное изделие какая уж тут экономия.
Хотя игроделы в некоторых случаях вполне умудряются экономить выпуская практически одинаковые игры с разной графикой и в данном случае экономия на масштабе есть. К ней же можно отнести использование библиотек но автор статьи это естественно проигнорировал.
Конечно, именно поэтому у нас в каждом языке кучи фреймворков и библиотек которые решают типовые проблемы разработчика. Если посмотреть на чем происходит экономия то основная часть как раз на переиспользовании модулей или имеющегося кода.
Автор говорит про другое.
Вот вы начинаете делать большую систему. Вы можете запланировать большой релиз — делать его полгода и потом выпустить в прод, или вы можете работать маленькими, например, двухнедельными релизами.
Выбор из этих двух вариантов не так уже очевиден. Многие менеджеры скажут, что работать большими полугодовыми релизами гораздо удобнее — можно посадить аналитиков и они спокойно напишут большое ТЗ, потом посадить разработчиков и они все запрограммируют, потом отдать на тестирование и тд. Так вот автор в статье приводит аргументы и показывает, что это не так. Что в ИТ с этим проблемы и выгоднее ПО выпускать маленькими партиями / релизами.
Вот вы начинаете делать большую систему. Вы можете запланировать большой релиз — делать его полгода и потом выпустить в прод, или вы можете работать маленькими, например, двухнедельными релизами.
Выбор из этих двух вариантов не так уже очевиден. Многие менеджеры скажут, что работать большими полугодовыми релизами гораздо удобнее — можно посадить аналитиков и они спокойно напишут большое ТЗ, потом посадить разработчиков и они все запрограммируют, потом отдать на тестирование и тд. Так вот автор в статье приводит аргументы и показывает, что это не так. Что в ИТ с этим проблемы и выгоднее ПО выпускать маленькими партиями / релизами.
это не отменяет того что экономию на масштабе он приплел совершенно не к месту
в смысле???
попытка получить экономию на масштабе в разработке ПО (по автору) — это когда вы пытаетесь разрабатывать и поставлять ПО большими релизами и мотивируете это тем, что много требований будет за раз реализовать эффективнее, чем если бы вы эти требования реализовывали маленькими партиями (релизами/версиями).
попытка получить экономию на масштабе в разработке ПО (по автору) — это когда вы пытаетесь разрабатывать и поставлять ПО большими релизами и мотивируете это тем, что много требований будет за раз реализовать эффективнее, чем если бы вы эти требования реализовывали маленькими партиями (релизами/версиями).
в прямом смысле
термин экономия на масштабе относится к массовому производству одинаковых изделий чего в программировании практически нет. Разбиение работы на части к этому термину отношения не имеет.
термин экономия на масштабе относится к массовому производству одинаковых изделий чего в программировании практически нет. Разбиение работы на части к этому термину отношения не имеет.
Тут выстроены неверные аналогии и автор почти доходит до этого момента в своих объяснениях. Давайте на примере строительства автомобиля.
Разработка ПО — это не производство готового автомобиля, а проектирование новой модели автомобиля с нуля. Причем людьми которые никогда раньше не строили автомобили. А заказчик вначале попросил транспортное средство, наподобие кареты с кучером, но без лошади.
И вот вы ему строите деревянный карт, с цепной передачей которую нужно крутить ногами. Заказчик возвращается и говорит что карт нифига не едет, а ноги быстро устают.
Вы находите специалиста по паровым двигателям, вместе с ним вкорячиваете этот аппарат в машину. Заказчик жалуется что она начала гадить дымом и ее нужно периодически заправлять углем.
Вам нужно изобрести двигатель внутреннего сгорания, даже зная устройство парового двигателя это может быть задача которую до вас никто никогда не решал. Тут другой тип топлива, тут другие требования к безопасности, тут нужно более высокое качество тех. процессов. Вы каким-то образом умудряетесь сделать свой первый двигатель.
И дальше начинается: а что-то он сильно греется — нужна система охлаждения. А что-то он сильно шумит — нужна изоляция от салона и снова повышения качества движущихся частей, смазка, вот это все. Мне дождик капает когда я еду — блин что же вы сразу не сказали что вам крытая карета нужна, а не открытая. А сбоку все равно задувает ветер — вам нужны стекла. А почему вонь в салоне — теперь нужна система отвода газов. На меня все таращатся как на ненормального — нужна тонировка стекол. А как-то им сложно управлять — нужна рулевая система. А я себе 5 пару обуви стер тормозя ногами — делаем тормозную систему. А я тут разогнался чуть быстрее и он развалился на ходу — нужно заменить деревянный кузов на железный, а у вас одни плотники в штате! срочно всех переучивать в кузнецы! нет нифига так не работает, выпуск новой модели стал занимать в 5 раз больше времени, вес сильно увеличился, вам нужна тонкая прочная сталь и возможность гнуть ее как попало. Хорошо если до вас это кто-то придумал, но теперь вам нужно все это найти, изучить, внедрить, усовершенствовать под свой процесс производства. И тут нет никаких исторических несоответствий: заказчик может потребовать у вас одновременно крышу из пальмовых листьев, чугунные амортизаторы, и бампер из смеси кевлара с углеволокном, для него это всего лишь еще одна деталь в автомобиле, вы же там специалисты.
И такие мелкие правки до бесконечности. Вам нужно построить собственный конвеер для производства (Agile + CI). Но каждое новое изменение все еще проектируется, собирается, вытачивается, подгоняется и тестируется вручную. И да, заказчик говорит что вы тратите слишком много его денег, поэтому это должен делать full-stack специалист, начиная от сбора требований с пользователей, рисования чертежей, написания документации, вырезания прототипов из пенопласта, вылизывания формы под дизайнерское решение, формовки заготовки из пластика, отливания ее в железе своими руками, финальной токарной полировки и установки на автомобиль, после этого разработчик самостоятельно должен сесть за руль и сделать пару кругов по автодрому и выматерившись начать с начала из-за того что теперь масло подтекает. Вам приходится заменять по 1 детали в готовом автомобиле, но так чтобы он не развалился на ходу, и не дай бог вам сделать колесо которое упирается в крыло, теперь надо переделывать всю переднюю часть автомобиля. Мелкие итерации это лишь способ быстро проверить жизнеспособность решения.
И вроде автомобиль уже готов и работает как надо, но потом заказчик узнает что дышать выхлопными газами вредно, CO2, глобальное потепление вот это все… Теперь вам нужно перестроить весь свой производственный процесс, найти новых специалистов, придумать как это будет работать с новой инфраструктурой. Кстати об инфраструктуре, заказчик захочет чтобы ваши автомобили использовал не один человек, а тысячи. Для успеха вам нужна инфраструктура которая позволит автомобилям заменить лошадей: дороги (более мощные компьютеры), заправки (данные). Но у вас их нет, есть максимум гравий и несколько мостовых, бензин делает 2 заводика и возить его приходится с собой в канистре, а до электричества в каждом доме и солнечных электростанции еще 50 лет. Вы можете с кем-то договориться на будущее, но запускать свой продукт вы будете в существующей инфраструктуре. Ваш автомобиль приходится одновременно подстраивать под то что есть и стараться менять под него окружение. При этом переход с угля на бензин, а с бензина на электричество очень сильно повлияет на ваш процесс производства.
По сути разработка ПО это весь 100-летний путь разработки автомобилей схлопнутый в несколько лет со всеми ее технологическими открытиями и инновациями, сделанный командой не-специалистов из 100 человек. Если вы пытаетесь вырасти от лаборатории в гараже до нефтеперерабатывающего завода и при этом удивляетесь что 10 человек раньше справлялись, а теперь перестали и сложность слишком выросла, то у вас проблемы не с процессом, а с головой.
Как уже говорили экономия на масштабе — это экономия на создании новых копии одного и того же продукта без изменений. В ПО она условно равна нулю, почему условно потому что ПО вы запускаете на компьютере который вам нужно купить, используете и платите за электричество и интернет. Если все то же самое переезжает в облако, то значит за сервера, датацентры, электроэнергию платит кто-то другой. И тут опять нет линейной экономии на масштабе, чем больше пользователей, тем больше мощностей надо на поддержание работы. А значит у ПО есть либо платные пользователи, либо вы продаете свое внимание рекламодателям, либо вы сами и есть товар.
Разработка ПО — это не производство готового автомобиля, а проектирование новой модели автомобиля с нуля. Причем людьми которые никогда раньше не строили автомобили. А заказчик вначале попросил транспортное средство, наподобие кареты с кучером, но без лошади.
И вот вы ему строите деревянный карт, с цепной передачей которую нужно крутить ногами. Заказчик возвращается и говорит что карт нифига не едет, а ноги быстро устают.
Вы находите специалиста по паровым двигателям, вместе с ним вкорячиваете этот аппарат в машину. Заказчик жалуется что она начала гадить дымом и ее нужно периодически заправлять углем.
Вам нужно изобрести двигатель внутреннего сгорания, даже зная устройство парового двигателя это может быть задача которую до вас никто никогда не решал. Тут другой тип топлива, тут другие требования к безопасности, тут нужно более высокое качество тех. процессов. Вы каким-то образом умудряетесь сделать свой первый двигатель.
И дальше начинается: а что-то он сильно греется — нужна система охлаждения. А что-то он сильно шумит — нужна изоляция от салона и снова повышения качества движущихся частей, смазка, вот это все. Мне дождик капает когда я еду — блин что же вы сразу не сказали что вам крытая карета нужна, а не открытая. А сбоку все равно задувает ветер — вам нужны стекла. А почему вонь в салоне — теперь нужна система отвода газов. На меня все таращатся как на ненормального — нужна тонировка стекол. А как-то им сложно управлять — нужна рулевая система. А я себе 5 пару обуви стер тормозя ногами — делаем тормозную систему. А я тут разогнался чуть быстрее и он развалился на ходу — нужно заменить деревянный кузов на железный, а у вас одни плотники в штате! срочно всех переучивать в кузнецы! нет нифига так не работает, выпуск новой модели стал занимать в 5 раз больше времени, вес сильно увеличился, вам нужна тонкая прочная сталь и возможность гнуть ее как попало. Хорошо если до вас это кто-то придумал, но теперь вам нужно все это найти, изучить, внедрить, усовершенствовать под свой процесс производства. И тут нет никаких исторических несоответствий: заказчик может потребовать у вас одновременно крышу из пальмовых листьев, чугунные амортизаторы, и бампер из смеси кевлара с углеволокном, для него это всего лишь еще одна деталь в автомобиле, вы же там специалисты.
И такие мелкие правки до бесконечности. Вам нужно построить собственный конвеер для производства (Agile + CI). Но каждое новое изменение все еще проектируется, собирается, вытачивается, подгоняется и тестируется вручную. И да, заказчик говорит что вы тратите слишком много его денег, поэтому это должен делать full-stack специалист, начиная от сбора требований с пользователей, рисования чертежей, написания документации, вырезания прототипов из пенопласта, вылизывания формы под дизайнерское решение, формовки заготовки из пластика, отливания ее в железе своими руками, финальной токарной полировки и установки на автомобиль, после этого разработчик самостоятельно должен сесть за руль и сделать пару кругов по автодрому и выматерившись начать с начала из-за того что теперь масло подтекает. Вам приходится заменять по 1 детали в готовом автомобиле, но так чтобы он не развалился на ходу, и не дай бог вам сделать колесо которое упирается в крыло, теперь надо переделывать всю переднюю часть автомобиля. Мелкие итерации это лишь способ быстро проверить жизнеспособность решения.
И вроде автомобиль уже готов и работает как надо, но потом заказчик узнает что дышать выхлопными газами вредно, CO2, глобальное потепление вот это все… Теперь вам нужно перестроить весь свой производственный процесс, найти новых специалистов, придумать как это будет работать с новой инфраструктурой. Кстати об инфраструктуре, заказчик захочет чтобы ваши автомобили использовал не один человек, а тысячи. Для успеха вам нужна инфраструктура которая позволит автомобилям заменить лошадей: дороги (более мощные компьютеры), заправки (данные). Но у вас их нет, есть максимум гравий и несколько мостовых, бензин делает 2 заводика и возить его приходится с собой в канистре, а до электричества в каждом доме и солнечных электростанции еще 50 лет. Вы можете с кем-то договориться на будущее, но запускать свой продукт вы будете в существующей инфраструктуре. Ваш автомобиль приходится одновременно подстраивать под то что есть и стараться менять под него окружение. При этом переход с угля на бензин, а с бензина на электричество очень сильно повлияет на ваш процесс производства.
По сути разработка ПО это весь 100-летний путь разработки автомобилей схлопнутый в несколько лет со всеми ее технологическими открытиями и инновациями, сделанный командой не-специалистов из 100 человек. Если вы пытаетесь вырасти от лаборатории в гараже до нефтеперерабатывающего завода и при этом удивляетесь что 10 человек раньше справлялись, а теперь перестали и сложность слишком выросла, то у вас проблемы не с процессом, а с головой.
Как уже говорили экономия на масштабе — это экономия на создании новых копии одного и того же продукта без изменений. В ПО она условно равна нулю, почему условно потому что ПО вы запускаете на компьютере который вам нужно купить, используете и платите за электричество и интернет. Если все то же самое переезжает в облако, то значит за сервера, датацентры, электроэнергию платит кто-то другой. И тут опять нет линейной экономии на масштабе, чем больше пользователей, тем больше мощностей надо на поддержание работы. А значит у ПО есть либо платные пользователи, либо вы продаете свое внимание рекламодателям, либо вы сами и есть товар.
Очень интересная реконструкция истории создания авто ).
По поводу того, что ПО имеет максимальную экономию на масштабе после того как оно разработано — об этом автор прямо пишет.
Не очень понял в итоге с чем вы согласны или не согласны. Поясните, пожалуйста.
По поводу того, что ПО имеет максимальную экономию на масштабе после того как оно разработано — об этом автор прямо пишет.
Однако будьте аккуратны: после того, как программное обеспечение разработано, эффект экономии на масштабе становится неограниченным. Мир переключается. Созданное программное обеспечение, вероятно, демонстрирует большую экономию на масштабе, чем любой другой продукт, известный человеку. (С экономической точки зрения, затраты на изготовление первого экземпляра чрезвычайно высоки, но затраты на изготовление идентичной копии (изготовление) по сути близки к нулю — «Ctrl-C Ctrl-V»).
Не очень понял в итоге с чем вы согласны или не согласны. Поясните, пожалуйста.
Говорить что в разработке ПО нет экономии на масштабе, это как говорить что в молоке нет глютена. А сравнение производства продуктов и ПО, это как сравнение огурцов и апельсинов. Экономия на масштабе — это про штамповку одинаковых деталей в промышленном масштабе, а не про проектирование конвеерных лент и строительство нового завода.
А с аргументами автора какими конкретно вы Не согласны?
Прочтите еще пару раз если вам не понятно с первого.
Используя неверные аналогии автор делает неверные предположения и получает неверные выводы.
«попытка получить экономию на масштабе в разработке ПО (по автору) — это когда вы пытаетесь разрабатывать и поставлять ПО большими релизами и мотивируете это тем, что много требований будет за раз реализовать эффективнее» это не имеет ничего общего с тем почему на самом деле используются итеративные подходы.
Реальная проблема разработки в том что вы не знаете что должно получиться (также как и заказчик), вы никогда раньше не строили точно такую же модель и вам приходится одновременно подстраиваться под изменения, учиться и экспериментировать с решениями и проверять их на пользователях.
Большие релизы эффективнее чем мелкие, если вы у вас заранее известны все требования и если вся ваша задача собрать Сокол Тысячелетия (Lego Star Wars 75192) из 7000 готовых кубиков, вам всего лишь нужна инструкция и кучу времени. Если вы строите его в натуральную величину, вам нужно в 1000 раз больше кубиков и дополнительные руки. Сложность никуда не денется, рекомендация «используйте маленькие команды» бесполезна. Проблема в том что хорошо распланированная разработка через waterfall требует высокой квалификации управленцев и инженеров, при этом никто не мешает вам в отдельных командах использовать agile, scrum, kanban и релизить чаще основного релиза для пользователей. И да это очень дорого. Знаю по опыту квартальных релизов в большом проекте с десятком команд, чуть менее 1000 участников, стоимостью в сотни миллионов долларов.
Используя неверные аналогии автор делает неверные предположения и получает неверные выводы.
«попытка получить экономию на масштабе в разработке ПО (по автору) — это когда вы пытаетесь разрабатывать и поставлять ПО большими релизами и мотивируете это тем, что много требований будет за раз реализовать эффективнее» это не имеет ничего общего с тем почему на самом деле используются итеративные подходы.
Реальная проблема разработки в том что вы не знаете что должно получиться (также как и заказчик), вы никогда раньше не строили точно такую же модель и вам приходится одновременно подстраиваться под изменения, учиться и экспериментировать с решениями и проверять их на пользователях.
Большие релизы эффективнее чем мелкие, если вы у вас заранее известны все требования и если вся ваша задача собрать Сокол Тысячелетия (Lego Star Wars 75192) из 7000 готовых кубиков, вам всего лишь нужна инструкция и кучу времени. Если вы строите его в натуральную величину, вам нужно в 1000 раз больше кубиков и дополнительные руки. Сложность никуда не денется, рекомендация «используйте маленькие команды» бесполезна. Проблема в том что хорошо распланированная разработка через waterfall требует высокой квалификации управленцев и инженеров, при этом никто не мешает вам в отдельных командах использовать agile, scrum, kanban и релизить чаще основного релиза для пользователей. И да это очень дорого. Знаю по опыту квартальных релизов в большом проекте с десятком команд, чуть менее 1000 участников, стоимостью в сотни миллионов долларов.
Разработка программного обеспечения не имеет экономии на масштабе.
Смотря где. Вот у меня например был serverless проект на лямбдах (nodejs). Вопрос — каждая лямбда должна быть отдельным проектом, или все лямбды должны быть в одном проекте.
С логической точки зрения первый вариант выглядит лучше, но когда мы началить плодить десятки проектов мы получили такой дикий оверхед на поддержку этого зоопарка, что в итоге слили все в один проект, сэкономив в итоге на многих параметрах.
Другой пример, когда относительно небольшой проект начинают разбивать на микросервисы, хотя там вполне хватило бы и монолита. И получают в итоге много головной боли и потраченного времени, вместо "скидки за объем"
Наверно так в любом продукте, где основные затраты составляет фонд оплаты труда и нет жесткого разделения на подгруппы. Выкопать ровную, соответствующую определённым допускам по ширине, глубине и полосе отвода (которые тоже проверяются вручную), траншею длиной 100 км силой только 500 землекопов с лопатой будет дороже, чем 100 участков по одному километру. Для этого придумана этапность и распараллеливание.
Все эти попытки уменьшения объема растут из простых ценностей Agile о целесообразности ранней поставки ценного программного обеспечения и выпуске работающего продукта как можно чаще. В головах эффективных менеджеров это интерпретируется как: «раз чаще и быстрее значит меньшего объема». В то время как для пользователей прежде всего важно «ценное ПО и работающий продукт».
Мне кажется только все совсем наоборот.
Есть анализ ситуации/сбор статистики/логика/аргументация/причинно-следственные связи и из этого вытекают какие-то решения, которые целесообразны для определенных ситуаций.
А уже потом некоторые решения облекают в форму «ценностей XXX» и доводят до широкого круга лиц просто потому-что так проще ))).
Кому охота разбираться с теорией очередей, законом Литла и тп? гораздо проще сформулировать пяток «ценностей» и рекламировать их )))
Правда отсюда же и возникают проблемы с внедрением того же Agile. Консультанты помохали флагами, люди пошли внедрять, но у них ничего не получается.
Автор статьи, конечно, тоже далек от научной точности, но все же он идет гораздо дальше. Если интересны научное обоснование принципов разработки ПО (в тч практик Agile), то рекомендую изучить книгу на которую в тч ссылается автор статьи (https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009).
Есть анализ ситуации/сбор статистики/логика/аргументация/причинно-следственные связи и из этого вытекают какие-то решения, которые целесообразны для определенных ситуаций.
А уже потом некоторые решения облекают в форму «ценностей XXX» и доводят до широкого круга лиц просто потому-что так проще ))).
Кому охота разбираться с теорией очередей, законом Литла и тп? гораздо проще сформулировать пяток «ценностей» и рекламировать их )))
Правда отсюда же и возникают проблемы с внедрением того же Agile. Консультанты помохали флагами, люди пошли внедрять, но у них ничего не получается.
Автор статьи, конечно, тоже далек от научной точности, но все же он идет гораздо дальше. Если интересны научное обоснование принципов разработки ПО (в тч практик Agile), то рекомендую изучить книгу на которую в тч ссылается автор статьи (https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009).
Для пользователей важно чтобы им не мешали работать
в том числе и ежедневными обновлениями.
Но где пользователи и где «эффективные» менеджеры
в том числе и ежедневными обновлениями.
Но где пользователи и где «эффективные» менеджеры
UFO just landed and posted this here
Дробить временную шкалу — это одно, а объем функционала — другое.
Т.е. заказчику не надо покупать молока на месяц вперед, это дорого, и оно может прокиснуть. Лучше каждый день по литру. Вдруг через неделю заказчик передумает и захочет кефира? Это и есть Аджайл.
А вот с функционалом все хуже. Может так статься, что 10 взаимосвязанных сервисов с (условно) 1 млн строк кода в каждом проще разрабатывать, чем 1000 взаимосвязанных сервисов по 10 тыс строк. Потому что есть риск вынести всю сложность на уровень взаимодействия между сервисами, и это станет адом эксплуатации. Тут нельзя однозначно сказать, все зависит от решаемой задачи.
Автор сравнил несравнимое… А зачем? Желтая пресса и красивые слова… Только зачем такое переводить для всех?
Принципы Agile дают понятное представление об индустрии и нет необходимости сравнивать еще с чем-то чтобы понять
Sign up to leave a comment.
Программное обеспечение дешевле в мелкой таре