А нужно ли столько софта?
hardsign задал очень правильный вопрос, который и стал заголовком этого поста. Я не уверен, что у меня есть на него правильный ответ, но я хотя бы попробую: софта нынче примерно столько, сколько и нужно, даже если субъективно результат и не очень нравится. А ниже занудное пояснение.
Сначала надо уточнить вопрос. По одному уточнению на слово.
Что такое "нужно"?
Это понятие варьируется от маниловских мечтаний и до необходимости реаниматологу решить по результатам fMRT, отключать ли больного от жизнеобеспечения. Как человек меркантильный, я предпочту урезать вопрос до экономики, и измерять две "нужности", одну отражённую в платёжеспособном спросе, и другую, управляющую поведением инвесторов. Возражение, что так я забываю про те положительные эффекты, которые даёт обществу бесплатный софт, я откидываю на том основании, что бесплатность получения этого софта не означает бесплатности всего последующего владения этим софтом, начиная от затрат времени покупателя, и заканчивая вполне платными сопровождениями, обучениями, докупками железа и т.д.
Что такое "софт"?
Можно было бы сказать, что софт это то, что программируют, а раз программируют, то на каких-то языках программирования. Но вот беда, вторым по популярности языком программирования формально является HTML+CSS, и тогда каждая страничка в Сети оказывается отдельной программой. А первым по популярности языком является JavaScript, в первую очередь для запихивания рекламы в эти странички. Но я не хочу считать себя "пользователем" рекламы. Поэтому я волюнтаристски отделяю "читателей" от "пользователей", и в сети считаю за одно "приложение" только то, куда я могу, например, залогиниться, и сделать там что-то осмысленное.
И ещё терминологическое уточнение, банальное для многих читателей, но не для всех. "Программа" и "программный продукт" --- два очень разных понятия. Программа --- кусок кода (плюс, возможно, запас каких-то данных), который какое-то оборудование в каком-то месте может исполнять. Программный продукт --- не только программа, а ещё и отлаженный способ её покупки и получения, документация к ней, и при необходимости техподдержка и прочие плюшки (а иногда и сертификаты организаций разной степени вредности). При этом далеко не каждая программа готова стать частью программного продукта без дополнительных проверок и доделок. Вполне возможно, что только автор программы знает, как её правильно запустить, или она работает только на том сочетании разного оборудования, которое есть под рукой у автора, или автор на ходу добавляет в программу недостающие куски, как только они оказываются нужными для обработки новых данных, не похожих на те, что были вчера и позавчера --- или всё перечисленное, вместе взятое. Неготовность быть частью продукта не обязательно означает, что программа плоха. Вполне может быть, что она была быстренько написана, чтобы упростить ровно один расчёт, и уже успешно исполнила своё предназначение и тем окупилась. Или программа крутится на веб-сервере и обслуживает уйму клиентов под непрерывным присмотром своих разработчиков, всё хорошо, никто и не собирался продавать её копии. Или компания взяла программиста в штат, чтобы он сделал программу "сначала для собственных нужд, а потом, может, и продавать её будем", успешно закрыла собственные нужды, но решила не продолжать. Главное, не путать два этих понятия.
Что такое "столько"?
Коров посчитать просто --- они большие и, языком юристов, "вещные"; они не могут добавляться быстро и незаметно, поэтому просто посчитай их ноги и подели на четыре. Если бы коровы копировались мгновенно и по практически нулевой себестоимости, я бы попробовал использовать другую модель коровьей экономики: фермеры, желающие обзавестись новой коровьей породой, объединяются в воображаемый кооператив, который за некую общую для кооператива оптовую сумму покупает воображаемую оптовую партию, одну на весь кооператив, а вопросы копирования игнорировал бы. С моделью "все пользователи выложили одну общую сумму за все копии" сами собой исчезают все сложности с кривыми спроса и предложения, customer surplus и т.п., а на правдоподобность последующих рассуждений это сильно повлиять не должно. Обычно разработчики действуют достаточно разумно, чтобы из имеющегося рынка для продукта выжать максимум, их риски обычно не в том, что они неправильно назначат цену на товар, или что-то вроде того, а в том, что завалят качество или сделают не тот функционал, который нужен, или пролетят по срокам/качеству и подарят рынок конкуренту. Раз так, то какая разница, какой формы была площадь под графиком номер покупателя --- цена его покупки, пусть будет просто прямоугольник. Кстати, эта модель стирает разницу между пакетными корпоративными и штучными частными закупками, ведь в конечном итоге в зачёт идут конкретные пользователи-люди, а как они "группировались" перед попаданием в одну общую итоговую группу, становится неважно.
Есть ещё три отличия от рынка коров. Во-первых, фермер может купить много одинаковых коров, и каждая следующая корова принесёт ему дополнительную пользу, а пользователю десять копий одной программы не нужны, даже вторая копия обычно не нужна. Во-вторых, фермеров в зависимости от состояния рынка может стать больше или меньше, а пользователей программ --- нет, потому что теперь фактически каждый дееспособный человек на Земле так или иначе является пользователем какого-то софта, хотя бы прошивки бабушкофона, и разница только в количестве наименований разных программ и в соответствующих цениках. В-третьих, мы с лёгкостью можем сказать, где заканчивается одна корова и начинается другая, но с программами всё запутывается, они могут интегрироваться друг с другом до такой степени, что непрофессионал даже не поймёт, что минуту назад и две минуты назад он использовал две разные программы. Этот момент надо запомнить особо, потому что с ним связаны большие деньги, а пока для целей бухучёта будем считать, что если что-то программное можно приобрести/лицензировать/заказать отдельно от других, то это "софт, адын штук".
Вопрос в меру сил уточнён, можно начинать разбираться с баблом.
Если я перепою Брукса, как Рабинович Карузо, то при цене разработки программы C, превращение программы в отчуждаемый программный продукт стоит дополнительные 2*C, итого 3*C, интеграция программы в среду других программ стоит дополнительные 2*C, итого 3*C, а чтобы получить программный продукт, интегрированный в экосистему других программных продуктов, надо доставать из кошелька 9*C: неважно, сначала утроить расходы интеграцией, или сначала утроить расходы продуктизацией, их потом придётся ещё раз утроить, оплачивая продвижение по другой оси в системе координат "интеграция -- продуктизация".
(На этом пересказ Брукса закончен, дальше мои среднепотолочные оценки, в которых Брукс не виноват.)
Со времён IBM S/360 софт стал сильно разнообразней, множители по упомянутым осям стали заметно различаться в разных подотраслях (в первую очередь из-за того, что под "работающей программой" подразумевают разное, и в это понятие "вползает" та или иная порция интеграции и/или продуктизации). Вместо значений 3 и 3 множители гуляют от 2 до 5. Раз так, можно было бы ожидать, что произведения этих множителей для разных программ более-менее равномерно заполняют диапазон от 4 до 25. На практике почти все произведения оказываются в коротеньком отрезке эдак от 8 до 10. Возможно, что 8*C--10*C это обычный предел терпения инвесторов, и те проекты, которые при получении 5*5*C успешно завершились бы, а то и окупились бы, просто хоронятся/застревают на более ранних стадиях. То есть удачливо сэкономивший на продуктизации может побольше потратить на интеграцию, или наоборот, но необычно большие затраты и на то и на другое означают не только непомерные расходы, но ещё и непомерные риски, что дело затянется, а конкурент успеет раньше. А необычно сэкономивший и на том, и на другом, и потративший всего 2*2*С или 2*3*С просто рано радуется --- конкурент не сэкономил и скоро выдаст менее сырой продукт, гонка только предстоит. У меня нет догадок лучше, критика и идеи всячески приветствуются.
Как бы то ни было, если продуктизация голенькой "отдельно стоящей" программы стоимости C почти всегда приводит к стоимости не более 5*C, а с продуктизацией и интеграцией получается не менее 8*C, никакие вольности в оценках не позволяют игнорировать очень высокие затраты на взаимную интеграцию программ. Казалось бы, в интеграции ничего принципиально сложного нет, достаточно всем соблюдать общие стандарты, а писать программы сразу в соответствии с готовыми стандартами должно быть проще, чем изобретать велосипеды. Так в том-то неожиданно и дело, что со стандартами оказывается проще не выборочно интеграция, а вообще всё. Как правило, появление стандартов в какой-то предметной области сопровождается почти одновременным появлением библиотек и прочих программных компонентов, реализующих эти стандарты и плюс ещё маленько сверх них. Правильное использование этих библиотек уменьшает не только стоимость интеграции, но и стоимость написания программ самих по себе, так что при уменьшении и числителя (стоимости интеграции) и знаменателя стоимости разрабоки программы) итоговое отношение стоимости более-менее сохраняется. Доставай из кошелька 3*С и радуйся, что хотя бы С уменьшилось.
Пользователи по очевидным причинам любят как можно более высокую степень интеграции. Раз уж пока ещё нельзя сделать одну универсальную программу с одной кнопкой "сделай, чтобы всё стало хорошо", пусть будет хотя бы программа, в которой делать хорошо придётся по частям и по этапам, но одна программа (или набор очень тесно интегрированных), а не много разных. Одна --- чтобы не надо было запоминать заморочки множества разношёрстных интерфейсов. Ещё важнее, если она будет одна, то не надо будет учиться обходить проблемы преобразования выходного формата одной "отдельно стоящей" программы, ответственной за пятый этап решения проблемы, во входной формат другой "отдельно стоящей" программы, обещающей выполнить шестой этап. Но любить-то они любят, а насколько они готовы за это переплачивать? И что ещё важно, повышение степени интеграции требует не только больших денег, но ещё и дополнительного времени на разработку; готовы ли пользователи ждать?
Мы застреваем в классическом треугольнике "цена-сроки-качество", только вместо "качества вообще" рассматриваем один из его аспектов, степень интеграции. И если в плоскости валяется такой треугольник, то над ним классическим же образом рисуются кривые спроса на интеграцию и предложения этой самой интеграции. Пока что они пересекаются в точке, под которой на шкале написано "кошмарный зоопарк", и быстро ситуация не изменится. Можно только понемножку давить на рынок, предлагая программистам технологии для удешевления некоторых задач интеграции.
Сначала надо уточнить вопрос. По одному уточнению на слово.
Что такое "нужно"?
Это понятие варьируется от маниловских мечтаний и до необходимости реаниматологу решить по результатам fMRT, отключать ли больного от жизнеобеспечения. Как человек меркантильный, я предпочту урезать вопрос до экономики, и измерять две "нужности", одну отражённую в платёжеспособном спросе, и другую, управляющую поведением инвесторов. Возражение, что так я забываю про те положительные эффекты, которые даёт обществу бесплатный софт, я откидываю на том основании, что бесплатность получения этого софта не означает бесплатности всего последующего владения этим софтом, начиная от затрат времени покупателя, и заканчивая вполне платными сопровождениями, обучениями, докупками железа и т.д.
Что такое "софт"?
Можно было бы сказать, что софт это то, что программируют, а раз программируют, то на каких-то языках программирования. Но вот беда, вторым по популярности языком программирования формально является HTML+CSS, и тогда каждая страничка в Сети оказывается отдельной программой. А первым по популярности языком является JavaScript, в первую очередь для запихивания рекламы в эти странички. Но я не хочу считать себя "пользователем" рекламы. Поэтому я волюнтаристски отделяю "читателей" от "пользователей", и в сети считаю за одно "приложение" только то, куда я могу, например, залогиниться, и сделать там что-то осмысленное.
И ещё терминологическое уточнение, банальное для многих читателей, но не для всех. "Программа" и "программный продукт" --- два очень разных понятия. Программа --- кусок кода (плюс, возможно, запас каких-то данных), который какое-то оборудование в каком-то месте может исполнять. Программный продукт --- не только программа, а ещё и отлаженный способ её покупки и получения, документация к ней, и при необходимости техподдержка и прочие плюшки (а иногда и сертификаты организаций разной степени вредности). При этом далеко не каждая программа готова стать частью программного продукта без дополнительных проверок и доделок. Вполне возможно, что только автор программы знает, как её правильно запустить, или она работает только на том сочетании разного оборудования, которое есть под рукой у автора, или автор на ходу добавляет в программу недостающие куски, как только они оказываются нужными для обработки новых данных, не похожих на те, что были вчера и позавчера --- или всё перечисленное, вместе взятое. Неготовность быть частью продукта не обязательно означает, что программа плоха. Вполне может быть, что она была быстренько написана, чтобы упростить ровно один расчёт, и уже успешно исполнила своё предназначение и тем окупилась. Или программа крутится на веб-сервере и обслуживает уйму клиентов под непрерывным присмотром своих разработчиков, всё хорошо, никто и не собирался продавать её копии. Или компания взяла программиста в штат, чтобы он сделал программу "сначала для собственных нужд, а потом, может, и продавать её будем", успешно закрыла собственные нужды, но решила не продолжать. Главное, не путать два этих понятия.
Что такое "столько"?
Коров посчитать просто --- они большие и, языком юристов, "вещные"; они не могут добавляться быстро и незаметно, поэтому просто посчитай их ноги и подели на четыре. Если бы коровы копировались мгновенно и по практически нулевой себестоимости, я бы попробовал использовать другую модель коровьей экономики: фермеры, желающие обзавестись новой коровьей породой, объединяются в воображаемый кооператив, который за некую общую для кооператива оптовую сумму покупает воображаемую оптовую партию, одну на весь кооператив, а вопросы копирования игнорировал бы. С моделью "все пользователи выложили одну общую сумму за все копии" сами собой исчезают все сложности с кривыми спроса и предложения, customer surplus и т.п., а на правдоподобность последующих рассуждений это сильно повлиять не должно. Обычно разработчики действуют достаточно разумно, чтобы из имеющегося рынка для продукта выжать максимум, их риски обычно не в том, что они неправильно назначат цену на товар, или что-то вроде того, а в том, что завалят качество или сделают не тот функционал, который нужен, или пролетят по срокам/качеству и подарят рынок конкуренту. Раз так, то какая разница, какой формы была площадь под графиком номер покупателя --- цена его покупки, пусть будет просто прямоугольник. Кстати, эта модель стирает разницу между пакетными корпоративными и штучными частными закупками, ведь в конечном итоге в зачёт идут конкретные пользователи-люди, а как они "группировались" перед попаданием в одну общую итоговую группу, становится неважно.
Есть ещё три отличия от рынка коров. Во-первых, фермер может купить много одинаковых коров, и каждая следующая корова принесёт ему дополнительную пользу, а пользователю десять копий одной программы не нужны, даже вторая копия обычно не нужна. Во-вторых, фермеров в зависимости от состояния рынка может стать больше или меньше, а пользователей программ --- нет, потому что теперь фактически каждый дееспособный человек на Земле так или иначе является пользователем какого-то софта, хотя бы прошивки бабушкофона, и разница только в количестве наименований разных программ и в соответствующих цениках. В-третьих, мы с лёгкостью можем сказать, где заканчивается одна корова и начинается другая, но с программами всё запутывается, они могут интегрироваться друг с другом до такой степени, что непрофессионал даже не поймёт, что минуту назад и две минуты назад он использовал две разные программы. Этот момент надо запомнить особо, потому что с ним связаны большие деньги, а пока для целей бухучёта будем считать, что если что-то программное можно приобрести/лицензировать/заказать отдельно от других, то это "софт, адын штук".
Вопрос в меру сил уточнён, можно начинать разбираться с баблом.
Если я перепою Брукса, как Рабинович Карузо, то при цене разработки программы C, превращение программы в отчуждаемый программный продукт стоит дополнительные 2*C, итого 3*C, интеграция программы в среду других программ стоит дополнительные 2*C, итого 3*C, а чтобы получить программный продукт, интегрированный в экосистему других программных продуктов, надо доставать из кошелька 9*C: неважно, сначала утроить расходы интеграцией, или сначала утроить расходы продуктизацией, их потом придётся ещё раз утроить, оплачивая продвижение по другой оси в системе координат "интеграция -- продуктизация".
(На этом пересказ Брукса закончен, дальше мои среднепотолочные оценки, в которых Брукс не виноват.)
Со времён IBM S/360 софт стал сильно разнообразней, множители по упомянутым осям стали заметно различаться в разных подотраслях (в первую очередь из-за того, что под "работающей программой" подразумевают разное, и в это понятие "вползает" та или иная порция интеграции и/или продуктизации). Вместо значений 3 и 3 множители гуляют от 2 до 5. Раз так, можно было бы ожидать, что произведения этих множителей для разных программ более-менее равномерно заполняют диапазон от 4 до 25. На практике почти все произведения оказываются в коротеньком отрезке эдак от 8 до 10. Возможно, что 8*C--10*C это обычный предел терпения инвесторов, и те проекты, которые при получении 5*5*C успешно завершились бы, а то и окупились бы, просто хоронятся/застревают на более ранних стадиях. То есть удачливо сэкономивший на продуктизации может побольше потратить на интеграцию, или наоборот, но необычно большие затраты и на то и на другое означают не только непомерные расходы, но ещё и непомерные риски, что дело затянется, а конкурент успеет раньше. А необычно сэкономивший и на том, и на другом, и потративший всего 2*2*С или 2*3*С просто рано радуется --- конкурент не сэкономил и скоро выдаст менее сырой продукт, гонка только предстоит. У меня нет догадок лучше, критика и идеи всячески приветствуются.
Как бы то ни было, если продуктизация голенькой "отдельно стоящей" программы стоимости C почти всегда приводит к стоимости не более 5*C, а с продуктизацией и интеграцией получается не менее 8*C, никакие вольности в оценках не позволяют игнорировать очень высокие затраты на взаимную интеграцию программ. Казалось бы, в интеграции ничего принципиально сложного нет, достаточно всем соблюдать общие стандарты, а писать программы сразу в соответствии с готовыми стандартами должно быть проще, чем изобретать велосипеды. Так в том-то неожиданно и дело, что со стандартами оказывается проще не выборочно интеграция, а вообще всё. Как правило, появление стандартов в какой-то предметной области сопровождается почти одновременным появлением библиотек и прочих программных компонентов, реализующих эти стандарты и плюс ещё маленько сверх них. Правильное использование этих библиотек уменьшает не только стоимость интеграции, но и стоимость написания программ самих по себе, так что при уменьшении и числителя (стоимости интеграции) и знаменателя стоимости разрабоки программы) итоговое отношение стоимости более-менее сохраняется. Доставай из кошелька 3*С и радуйся, что хотя бы С уменьшилось.
Пользователи по очевидным причинам любят как можно более высокую степень интеграции. Раз уж пока ещё нельзя сделать одну универсальную программу с одной кнопкой "сделай, чтобы всё стало хорошо", пусть будет хотя бы программа, в которой делать хорошо придётся по частям и по этапам, но одна программа (или набор очень тесно интегрированных), а не много разных. Одна --- чтобы не надо было запоминать заморочки множества разношёрстных интерфейсов. Ещё важнее, если она будет одна, то не надо будет учиться обходить проблемы преобразования выходного формата одной "отдельно стоящей" программы, ответственной за пятый этап решения проблемы, во входной формат другой "отдельно стоящей" программы, обещающей выполнить шестой этап. Но любить-то они любят, а насколько они готовы за это переплачивать? И что ещё важно, повышение степени интеграции требует не только больших денег, но ещё и дополнительного времени на разработку; готовы ли пользователи ждать?
Мы застреваем в классическом треугольнике "цена-сроки-качество", только вместо "качества вообще" рассматриваем один из его аспектов, степень интеграции. И если в плоскости валяется такой треугольник, то над ним классическим же образом рисуются кривые спроса на интеграцию и предложения этой самой интеграции. Пока что они пересекаются в точке, под которой на шкале написано "кошмарный зоопарк", и быстро ситуация не изменится. Можно только понемножку давить на рынок, предлагая программистам технологии для удешевления некоторых задач интеграции.