В 2018 году в серьёзном медицинском журнале BMJ была опубликована совершенно серьёзная статья: Parachute use to prevent death and major trauma when jumping from aircraft: randomized controlled trial.

Цель исследования: выяснить, уменьшает ли использование парашюта травматизм при прыжке из самолёта. Схема эксперимента: рандомизированное контролируемое испытание. Участники: 92 пассажира самолёта в возрасте от 18 лет, 23 из них согласились и были случайным образом разбиты на группы.

Короче, абсолютно та же схема, какая применяется в стандартных медицинских исследованиях.

Результат: использование парашюта никак не уменьшает смертность от прыжка из самолёта.

В чём же проблема? В самом эксперименте, вот тут ссылка на фотографию, как он проводился. Сначала её откройте и посмотрите, а потом читайте дальше.

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

«Фейсбук» — плохая цель, естественно, тут может быть что угодно вместо него, например: microsoft, outlook, excel, twitter, dropbox. Фразы типа «Наш продукт — это убийца экселя» годятся только для жёлтой прессы, а во внутреннем жизненном цикле продукта они не должны фигурировать в принципе. Проблема здесь всё та же: аналитика и сбор требований. Я гарантирую, что вы в принципе не сможете сделать продукт, который сможет полностью у всех заменить excel, скажем. Ведь это настолько сложная система, что у каждого пользователя могут быть абсолютно уникальные представления, что же такое «эксель». Для кого-то это инструмент для печати прайс-листов, для кого-то — вычисление статистических данных, а кто-то весь бизнес построил на эксплуатации некорректного поведения продукта в конкретной ситуации, причём он об этом даже не подозревает.

Фейсбук — это не просто социальная сеть, состоящая из стандартных функциональных блоков. Excel — это не просто табличный вычислитель. Outlook — не просто почтовый клиент. Dropbox — не просто синхронизация файлов. И так далее, можно для любого даже не самого сложного продукта такое написать.

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

К сожалению, потенциальные клиенты сами неспособны сформулировать даже собственные потребности. Разработчики не сами ставят себе цель, а исходят из пожеланий клиента. А они приходят с фразой типа «хотим всё как в аутлуке», а максимум — со списком фич аутлука, которые они считают, что используют, при этом оставляя за кадром, естественно, критичные нюансы, так как просто их не замечают, как люди не замечают воздух, которым дышат. Часто можно встретить мнение, что типа SRS (software requirements specification) нужно выработать из потребностей заказчика (customer needs). Формально это действительно так, вот только заказчик не способен предоставить эти самые needs в пригодном для использования виде. Заказчик приходит с семантической кашей в мыслях и текстах и вам нужен специальный человек, способный из этой каши сначала выделить needs, согласовать их (а это отдельная проблема — убедиться, что противоположная сторона всё поняла так же, как и вы!) и только после этого приступить к SRS.

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

Есть подозрение, что YouTube Music — это плод подковёрной борьбы среди гуголовских менеджеров.

Уже давно не секрет, что основной мерой успеха в гугле (да и в других корпорациях) является shipping. Если ты не даёшь новый продукт, то не получаешь серьёзного повышения. «Новый продукт» — это такое собирательный термин для видимых метрик. Подробно эта тема раскрыта, например, в этом тексте: Why I Quit Google to Work for Myself. (Если коротко: решение от твоём повышении принимают совершенно посторонние люди, которые ориентируются только на эффектные метрики.)

Но ещё в 2000 году Джоэл Спольски написал свой самый знаменитый текст Things You Should Never Do, Part I, основной тезис которого: никогда не переписывайте продукт с нуля. Сомневаюсь, что в гугле этого текста не читали. Но так как менеджерам в принципе глубоко наплевать на собственно продукт, а интересует их только повышение плюс строчка в резюме, получаем нескончаемый поток ненужного «нового» софта и воняющие кучи заброшенного старого.

Находиться в команде умирающего продукта очень вредно для перспектив.

В конце восьмидесятых в СССР решили вдруг начать выпускать собственные CD. К тому времени в мире количество проданных компакт дисков превысило общее количество грампластинок, а плееров продавали сотни и сотни тысяч ежегодно. В СССР, естественно, всё оборудование и материалы пришлось покупать за границей, так как в стране в принципе не существовало подобных промышленных технологий. Ну да не в первый раз, у нас даже спички выпускались на импортных производственных линиях.

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

Неофициальное открытие предприятия — его назвали Московский опытный завод «Грамзапись» — состоялось 10 декабря 1989 года, оно было построено в одном из старых корпусов фирмы «Мелодия» усилиями иностранных специалистов. Помимо производственных линий было также установлено оборудование для высокой очистки воздуха, что было абсолютно необходимо для техпроцесса. Бюджет предприятия составлял более 11 млн долларов, огромная сумма!

Но было одна проблема — проигрывателей для дисков в стране не существовало в принципе. Усилиями нескольких радиозаводов удалось собрать из импортных комплектующих пару тысяч проигрывателей (или только сотен, история очень мутная). Из отечественных собрать и уложиться в смету не получилось (максимальная цена плеера должна быть не более 1200 рублей, фантастическая сумма по тем временам). Да и вообще радиоэлементная база была очень слабая для подобной техники. Собственных схем тоже не было, поэтому всё копировали за рубежом.

Худо-бедно запустили, выпустили первый диск, вот этот или этот, потом ещё и ещё, всё — сначала разнообразная классическая и ранняя музыка, потом отечественный рок и попса («Алиса», Кобзон, Пугачёва), всего до 1991 года было выпущено около 150 CD.

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

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

Божественной силы цитата:

I don't think CS is a high social status field at all. You're deluding yourselves. Outside of our peers also in the industry nobody cares that you're a staff engineer at Google. Absolutely nobody. They'll assume you're doing IT work like the characters in the IT Crowd if they even bother to think about it at all and haven't already walked away.

Here's a concrete example to make it really obvious.

How many computer scientists are there in the Lords in the UK? I'm not sure there's any. There are nearly 800 lawyers, doctors, religious ministers, biologists, physicist, mathematicians, philosophers, business people, politicians, authors, composers. A computer scientist who defines the field for half a century is lucky to get knight bachelor.

Look at similar establishment institutions elsewhere. Are there any computer scientists in the Senate in the US? Are computer scientists often invited to lead major public bodies? How many computer scientists become deans of universities compared to other fields?

The social status of computer scientists is zero.

Если вы любите детективы, очень, очень рекомендую роман «Невидимый хозяин». Его очень долгое время не было в электронном виде, пока в 2018 года один хороший человек не распознал и не вычитал: http://lib.rus.ec/b/652487

Для затравки скажу, что именно с этого романа Агата Кристи спёрла сюжет «Десяти негритят», причём очень уныло и тоскливо. В этой же книге всё кипит и бурлит, почти как у Жюля Верна.

https://www.youtube.com/watch?v=kdfTuE9XHas

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

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

The unplanned impact of mathematics

В статье собрали несколько примеров, как вроде бы совершенно абстрактные и никому ненужные области математики внезапно нашли прикладное применение, да ещё какое.

Оказывается, гугл банит или демонетизирует видео, в которых упоминается covid или coronavirus, вот буквально этими словами. Поэтому люди, живущие за счёт ютубовского видео, вынуждены тщательно фильтровать текст и вместо covid/coronavirus использовать эвфемизмы типа “the current situation”. Слово, Которое Нельзя Называть.

«…Термин MITM вызвал недовольство из-за гендерной привязки, вместо него было предложено использовать слово PITM (people-in-the-middle).»

Какой же ад творится…

Статистика в прикладном применении — очень тонкая и неоднозначная штука. Вот классический пример: По статистике, люди, не употребляющие алкоголь в принципе, находятся в группе риска по заболеваниям печени.

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

Так что к любым статистическим исследованиям нужно относиться очень осторожно и аккуратно.

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

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

Проблема и одновременно преимущество UML — для его использования и понимания нужно кристально ясное понимание. UML по сути — это небольшое щупальце, которое пролезло из чистой академической среды в прикладную область программирования. Но так как изначально это очень сложная для понимания система понятий и связей между ними, в айти UML не смог прижиться глобально. Да, куча людей весьма ограниченно используют какие-то из диаграмм, чаще всего это class и sequence diagrams. Но этим всё и ограничивается, хотя возможностей по описанию строения системы и её поведения в UML гораздо больше, но они уж очень сложные и непонятные.

А ещё по UML очень мало толковых книг, в бо́льшей части которых делается упор на объектно-ориентированность языков программирования, отчего создаётся ложное ощущение, что это всё про OOP only. Но нет, широта охвата гораздо больше: жизненный цикл разработки (реализация, внедрение и т.п.), понятия и связи между элементами предметной области. И UML может использоваться не только архитекторами и кодерами, но вообще всеми участниками процесса разработки, для каждого найдётся свой уровень диаграмм.

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

Есть две малопересекающиеся реальности (realms) в UML.

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

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

За свои годы работы в ИТ я проработал "архитектором ПО" 3-5 лет, смотря как классифицировать совмещение с другими ролями.

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

Что я наблюдаю в последние годы:
1. Очень многие архитекторы пишут что язык моделирования UML мёртв. Действительно я практически не вижу UML диаграмм в хороших примерах и во многих областях они словно исчезли полностью. Вместо этого используют всё чаще модели C4 (Context, Containers, Components and Code) сделанные в нотации "boxes and lines"
2. Есть ощущение что многое сместилось в сторону легковесного описания архитектурных решений, таких как Architecture decision record (ADR) со структурированным описанием решений в Markdown
3. Восхождение и падение микросервисной архитектуры. О ней всё ещё говорят, но мало кто может показать живой пример с обоснованием и демонстрацией. За исключением микросервисов которые являются частью облачных платформ.
4. Каждый разработчик теперь мини-архитектор. Современное ПО состоит из множества "кубиков" и, зачастую, нужно лишь написать код для их "склейки".
5. Во многих процессах разработки облачные решения/продукты/API стали неотъемлимой частью архитектуры. Cloud-as-a-code - всё более распространённая концепцияи владельцы крупных облаков всячески это продвигают.
6. Нарастающее использование low-code/no-code платформ
7. Всё больше [Word]Ops. DevOps, DataOps, GitOps и, наконец, NoOps для полностью автоматической инфраструктуры.


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

#software #it

Очередное американское техническое чудо: https://youtu.be/qFezqz2Wcdo

По сути это короткий диафильм со звуком. Удивительно, что в СССР этот девайс не своровали. Или своровали, но это было такой редкостью, что никто не видел?

Почему-то мало кто поднимает тему эксплойтов NLP и прочего ML.

Как только эти технологии начнут интенсивно использоваться, люди начнут интенсивно их обманывать. Это, конечно, хорошо, что ML-движок может на «чистых» текстах отлично отработать классификацию. А если тексты будут специально подхачены, чтобы целенаправленно обманывать AI/ML/NLP/etc? Причём для обмана будут использоваться современные технологии! И уже есть примеры, где на картинке расставляется несколько точек в определённых местах, из-за которых полностью ломается технология распознавания, но человек прекрасно видит, что именно на картинке изображено.

Это, кстати, очень старая тема, которую ещё Лем поднимал в «Стиральной трагедии» — новые технологии форсятся исключительно со «светлых» и «оптимистичных» позиций, интересы злоумышленников и эксплойтеров полностью игнорируются, а потом ВНЕЗАПНО выясняется, что всё сломали. И так повторяется раз за разом.

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

Мы живём в очень динамичном и быстром времени, значения терминов меняются не только во времени, но и в пространстве. Не существует единого всеобщего словаря, где бы все слова однозначно определялись. В каждой предметной области, в каждом контексте у слова может оказаться своё значение, причём не одно. И люди обычно мыслят значениями, а не словами, поэтому для консенсуса критично важно, чтобы все участники выстроили в голове единую локальную систему понятий, чтобы в ней слово «объект», например, создавало в голове у каждого одинаковое значение. Как только значения начинают «плавать», консенсус либо распадается, либо вообще не возникает в принципе. Но это ещё не самое плохое, самое — это когда у каждого создаётся своё представление о консенсусе и они не совпадают. В итоге все считают, что договорились, а по факту — нет.

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