blog vs telegram vs соцсети

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

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

Старый добрый web погибает. Раньше реклама была "сайт три дабл-Ю что-то там", сейчас это скорее tg-канал или приложение. Соцсети туда же.

Вместе с этим меняется и пространство доступной информации. Сама система URL, на анализе которых были построены поисковики вроде гугла/яндекса уходит в историю. А крупные агрегаторы информации, тот же телеграм, соцсети и маркетплейсы обладают огромным массивом информации, на котором учат LLM и профилируют пользователей пользователей. Соцсети, мессенджеры и маркетплейсы знают типичного пользователя лучше спецслужб и, владея такой информацией, потенциально имеют больше власти, чем спецслужбы государств. И да, все данные, которые там принадлежат соответствующим платформам, они продают и сами данные, и основанные на них продукты. На подходе цифровой надзор и контроль.

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

Может лучше старый добрый web?

К природе технологических революций

Интересное исследование от Маккинзи о производительности экономики и как эта производительность распределяется и растёт. Несколько неочевидных моментов:

  • Рост производительности отдельных компаний приводит к росту экономики
  • Небольшое количество компаний вносит основной вклад в рост производительности. В США 5% компаний это 80% прироста производительности.
  • Производительность растёт в результате новых путей создавать/масштабировать ценность

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

Полное исследование в pdf, нашим "импортозаместителям" на заметку.

Halloween docs

Осенью далёкого теперь 1998 года из в сеть утекли так называемые Хеллоуинские документы. Это внутренняя аналитика Microsoft по вопросам конкуренции её продуктов с Linux и в целом с открытым программным обеспечением. Это крайне интересное чтиво, как в первоисточнике, так и с комментариями Эрика Раймонда. Кто интересуется внедрением ИТ-систем, интеграцией и даже разработкой ПО полезно хотя бы ознакомиться с этой историей. И точное необходимо кто развивает ИТ-бизнес или метит в фаундеры, а также любому бизнесу, завязанному ключевым образом на ИТ.

А история следующая. В 90-е годы Майкрософт вполне себе хорошо жил на рынке серверных операционных систем. Даже больше: MS вместе с Интелом (=wintel) были такими же столпами индустрии в корпоративном ИТ, как сейчас Nvidia с OpenAI в искусственном интеллекте. Unix в разных вариантах использовался, но имел огромные сложности как коммерческий продукт, а Linux был вообще уделом маргиналов и прочих гиков. Основной софт писался под Windows и основное внимание "денег" было направленно в wintel.

В хеллоуинских документах Linux и OSS уже признается как серьезная угроза бизнесу MS. Открытые протоколы, эффективная архитектура ОС, работа с сетью, расширяемость, масштабируемость и многое другое в линуксах было сделано изначально лучше. Например, такая выдержка:

Linux Operating System

The Next Java VM?

The Linux OS is the highest visibility product of the Open Source Software (OSS) process. Linux represents a best-of-breed UNIX, that is trusted in mission critical applications, and — due to it’s open source code — has a long term credibility which exceeds many other competitive OS’s.

Linux poses a significant near-term revenue threat to Windows NT Server in the commodity file, print and network services businesses. Linux’s emphasis on serving the hacker and UNIX community alleviates the near-medium term potential for damage to the Windows client desktop.

In the worst case, Linux provides a mechanism for server OEMs to provide integrated, task-specific products and completely bypassing Microsoft revenues in this space.

Через 15 лет Java-программисты действительно "захватят" мир. И Linux действительно станет платформой для многих программных решений. Кроме жавы, станут очень популярными разные питоны, руби и прочие, которые, конечно же, в серверном варианте тоже работают на линуксах. Многое из хеллоуинских доков реализовалось и произошло это по фундаментальным причинам и архитектурным преимуществам линуксов. Майкрософт практически потерял рынок серверных ОС и во многом интернета.

Архитектура критически повлияла и на развитие смартфонов, о чём в доках ни слова, тогда об этом "не мечтали". Apple свои айфоны делала под iOS, который потомок BSD. Google выбрал в качестве платформы Linux и получился Android. Обе компании сделали свои экосистемы на этих решениях. Майкрософт пыталась сделать свою ОС под смартфоны и она не получила развития, даже покупка Нокии не помогла.

С позиции более чем 25-летней давности произошедшее уже далёкая история. Но так и произошло! Главный вывод: Архитектура на долгосроке определяет развитие.

Выбор технологий под проект

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

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

  1. Для небольшой инфраструктуры лучше избегать ресурсоёмких технологий, какими бы хорошими, модными и полезными они ни были
  2. Когда использовать технологию становится целесообразно обычно лучше её внедрять на новой отдельной инфраструктуре, а не вносить изменения в рабочую старую.

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

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

Разработка ПО полвека назад

Так Фредерик Брукс описывает разработку и тестирование софта примерно полвека назад:

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

(…)

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

Люди работали круглосуточно, чтобы машины не простаивали. Еще 20-30 лет назад крупное ПО полностью компилировалось раз в сутки и код выкладывался на тестирование. Там же:

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

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

(…)

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

Сейчас по ночам обычно спят, а инструменты всего цикла разработки ПО поменялись. У почти каждого разработчика в арсенале виртуальные машины, контейнеры и прочие докеры для экспериментов и не только. Тестировать и выкладывать даже большой код можно настолько часто, насколько это позволяет местный DevOps.

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