Богатая на события неделя! Крах айти

Это не с банками проблема, а с ИТ конторами.

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

В американских продуктах есть своя специфика развития. На старте мало кто думает о деньгах, компании привлекают их позже за счёт венчурных инвестиций. А в сложное для мировой экономики время инвесторы не спешат рисковать и вкладываются в более предсказуемые проекты.
Прошедший год уже получил звание самого худшего периода для технологической индустрии за последние 15 лет, со времен мирового экономического кризиса. Последний начался в 2008 г. и продлился почти 6 лет, и по масштабам и последствиям его сравнивали с Великой депрессией.
Причина? 
Причина в менталитете современных айтищников, которые даже толковое приложение написать не могут! 
Еще кодеры присвоили себе права на интернет:

Но!
Принципы, по которым строится Интернет, впервые были применены в сети ARPANET, созданной в 1969 году по заказу американского военного агентства DARPA.
Прообразом цифровой связи был телетайп. Телетайпная сеть только Федерального управления гражданской авиации США в 1938 году превысила 21 тыс. миль, охватив почти все штаты. С появлением компьютеров телетайпные аппараты присоединялись к ЭВМ и могли использоваться в качестве терминалов. Соответствующие каналы связи использовались крупными корпорациями, государственными ведомствами и в военных системах.
Бедные военные! 

Американской исследовательской программой в направлении быстрой передачи сообщений руководил Джозеф Ликлайдер, опубликовавший в 1962 году работу «Galactic Network». Благодаря ему появилась первая детально разработанная концепция компьютерной сети. Она была подкреплена работами Леонарда Клейнрока — он описал технологию, способную разбивать файлы на части и передавать их различными путями через сеть (1961—1964).

В 1962 году Пол Бэран из RAND Corporation подготовил доклад «On Distributed Communication Networks». В его предложении сеть напоминала рыбацкий невод. Все узлы наделены способностью маршрутизировать трафик, каждый из них связан с несколькими другими узлами. Он предложил децентрализовать систему узлов связи (все региональные узлы связи в сети равноправны), которая даже при разрушении её части будет работоспособна. Предлагалось передавать сообщения в цифровом, а не в аналоговом виде. Само сообщение предлагалось разбивать на небольшие порции — «пакеты», и передавать по распределённой сети все пакеты одновременно. Из принятых в месте назначения дискретных пакетов сообщение заново «собиралось».
Бедные инженеры!
Теперь какой-то программист-недоучка указывает людям как им распоряжаться тем, что создано трудами инженеров!
Еще электричество из розетки и компьютеры из магазина.

Вся правда про помойку Айти:

Самым главным врагом бережливого производства является потери — действия, на которые расходуются как временные, так и материальные ресурсы, но которые не добавляют ценности товару или услуге для потребителя. Потери на японском языке звучат как «Муда»(как называются люди, которые создают потери — умолчим), а на английском «Waste».

Ценность — создается производителем, а определяется потребителем.

В классической теории бережливого производство были выделены 8 видов потерь:

Перепроизводство
Ожидание
Запасы
Излишняя транспортировка
Излишнее перемещение людей
Брак
Излишняя обработка
Айти (Это потери, которые возникают в результате производства продукции или оказания услуги с теми качествами, которые потребителю не нужны, и он не готов за них платить).
Пример — приложение для телевизора с набором дополнительных функций, которые не нужны потребителю, изготовление множество копий документов, когда необходима только одна.

ЭТО БЫЛО В СССР!
Вместо айтишников были АСУшник!
Многолетними стараниями многих и многих советских научных и проектных контор слово «АСУ» и глагол из него – «асучивание» – стали синонимами деятельного безделья, пустопорожней имитации, псевдонаучной фанаберии. И это чистая правда. Вот, как-то свалился вдруг в контору проект, даже название помню – АСП СОУ – «Автоматизированная Система Проектирования Систем Организационного Управления». Во как! Махонький компонентик эскизного проекта первой очереди АСУ СССР, сметной стоимостью в триллион рублей.
Там эскизный проект заканчивался в 2000-м году (дело было в 85-м), а ввод в эксплуатацию первой очереди – аж в 2050-м. Гуляй, не хочу!

Как вообще появились ваши питоны?
Замысел был такой: интерпретатор языка и программный редактор, простенькую операционную систему и набор утилит – все это «вшить» в машину, чтобы человек (не только и не столько программист, но грамотный инженер или ученый, а в последствии быдлокодер) включил ее и сразу начал работать – составлять несложную программу, тут же ее отлаживать, выполнять и анализировать результаты – все в диалоговом режиме.
Ну, вот пример: простейшая программа прочностного анализа, скажем, расчет балки по формулам сопромата. Что напишет умеющий программировать инженер-расчетчик: две-три строчки – ввод исходных данных, две-три строчки – собственно вычисления и четыре-пять строчек – печать результатов расчета. Всей программы – десяток строк кода. И написание ее займет от силы полчаса. Ну хорошо, если человек только осваивает компьютер, – два часа. А дальше инженер будет этой программой пользоваться всякий раз, когда ему надо посчитать балку.
Сейчас можно просто считать в Эксель.

Программист профи — это не про програмирование:

Теперь представим, что задание написать программу расчета балки получил профессиональный программист. Первое, что он сделает… нет, не бросится к компьютеру программный код писать, он вооружится блокнотом и пойдет «пытать» инженера-расчетчика: итак, какие же у нас исходные данные? Геометрические размеры – пролет балки и ее сечение. Ну, допустим, простейший случай – брус, высота и ширина. OK. И что программа должна делать, если пролет нулевой? Выдать сообщение об ошибке и остановиться? Какое сообщение? OK, записываю. А если пролет отрицательный? Как это может быть? Да элементарно, рука дрогнула, случайно на кнопку «минус» нажала. Так чтó, выдать сообщение об ошибке и остановиться или напечатать предупреждение, поменять знак числа и продолжить? Теперь аналогичные вопросы касательно высоты и ширины. OK, записываю...

Обычно, к этому моменту «подследственный» начинает звереть и ерзать на стуле, а ведь мы, по-хорошему, еще даже не начинали. Проверка на допустимые значения параметров по отдельности, это так… даже не разминка. Переходим к проверке соотношений параметров. Формулы сопромата для расчета изгиба балки базируются на допущениях теории Эйлера-Бернулли, коими не буду морить читателя, но скажу лишь, что результаты расчета хорошо согласуются с экспериментом, когда балка – действительно балка, т.е. нечто такое удлиненное по сравнению с сечением (но не слишком). Скажем, книжная полка: пролет метровый, а доска дюймовая. В самый раз. Или брус перекрытия пролетом шесть метров, с высотой сечения 20 см. Тоже нормально. А если мы восьмидюймовым брусом перекроем пролет в в один фут, то это как? А это, извиняюсь, уже не балка будет и считать такую конструкцию (скорей похожую на стеновую панель) надо совсем по другим формулам. И если двухметровый пролет перекроем, к примеру, миллиметровым металлическим листом или затянем пленкой, как в теплицах, то это тоже не будет балкой и считать придется по формулам теории все того же вездесущего Леонарда Эйлера, только совсем другой теории – статики гибкой нити. Инженер все эти вещи «печенкой чует», он интуитивно классифицирует и выбирает метод расчета (а хороший инженер и считает-то «для очистки совести»; он заранее знает результат, моделируя работу конструкции – сопротивление материала – каким-то необъяснимым, помимо сознания, способом, но при этом – безошибочно и весьма точно; если он настоящий инженер, конечно).

Увы, компьютер начисто лишен интуиции и все «входные» ограничения требует формулировать явно и однозначно. Даже для нашего примитивнейшего случая это далеко не просто… А кстати, мы тут оперируем метрами, сантиметрами, дюймами. А ведь для расчета все размеры надо привести в одну единицу измерения. В какую? В сантиметры? OK. И для входных данные считать, что все задано в сантиметрах? Ах, пусть пролет в метрах, а сечение в сантиметрах? А дюймы-футы? Ага, значит прежде задания размеров из меню выбирается система измерений: метрическая или имперская. А если пользователь ввел в метрах-сантиметрах, а потом решил пересчитать в дюймы-футы? Ага, вводим специальный пункт меню «пересчет». А может пусть указывает единицу измерения при каждом числе? Неудобно? Тогда, значит, пусть будут «правила по умолчанию», возможность выбора системы измерений из меню, режим пересчета, а дополнительно еще чтоб можно было указать единицу измерения при любом индивидуальном размере. Уф! Теперь это все запрограммировать и будет… всего навсего будет ввод геометрических размеров. А еще у нас есть ввод физико-механических свойств материала. Для простейшего изотропного линейно-упругого материала это два числа – модуль Юнга и коэффициент Пуассона. Наше счастье, что второй – безразмерный. Зато первый… та же головная боль с единицами измерений: континентальные килограммы на квадратный сантиметр или может имперские килофунты на квадратный дюйм, а то и вовсе новомодные мегапаскали. И всякие пересчеты между ними. Плюс, конечно, проверки на допустимые диапазоны значений (для обоих параметров) и диагностические сообщения в случае нарушений… А еще у нас ввод нагрузки: проверки, игры с единицами измерений и пересчетами, диагностические сообщения… И это мы топчемся пока всего лишь на вводе данных. А потом еще будет сам расчет, где программист, помимо двух строчек расчетных формул, будет долго и нудно специфицировать все мыслимые и немыслимые ошибки вычислений, реакции на них и опять же диагностические сообщения. Посчитав, наконец, приступаем к печати результатов. Так, во-первых короткая распечатка для рабочих нужд: вывод на экран или консольную пишущую машинку только чисел и минимальных обозначений при них. Теперь дальше: печать в табличной форме для многократных прогонов – чтоб сравнивать варианты. Эх, еще бы графики-эпюры построить. Не беда, что не производятся пока графические принтеры и дисплеи – примитивные графики можно «рисовать» звездочками на текстовых принтерах. И еще не все. Нужна «официальная», полная распечатка, которая будет подшиваться в проект со всеми, кстати, реквизитами проекта (которые тоже надо вводить, как и параметры, задающие форматирование и управляющие процессом печати)...

Ну вот, вроде бы все. На собеседования с будущим пользователем программы ушел хорошо если один рабочий день, а то и два (это называется на нашем жаргоне «обследованием» или «постановкой задачи»). Думаете, теперь-то программист пошел программировать? Ха, как бы не так! Он пошел писать документ под названием «техническое задание» и хорошо, если сам наберет его на компьютере и там же отпечатает. Тогда за пару-тройку дней справится. А вот если он пишет от руки на бумаге, а потом печатают девицы из машбюро, тогда, считай, уйдет неделя. Затем документ читается и согласовывается пользователем (почти всегда при этом – уточняется, правится и переписывается). Наконец утверждается начальством и… всего лишь две-три недели спустя программист приступает собственно к программированию. Помните, что инженер уложился в десять строчек кода? Так вот, программисту со всеми этими проверками, диагностиками и пересчетами придется написать эдак строк двести-триста...
Понятно, что никто не затеет многонедельную бодягу ради одной программки, реализующей один частный вид расчета. Программисту если уж закажут, то какой-нибудь пакет прочностных расчетов, например, балок для доброй сотни разных типов сечений, нагрузок, краевых условий, характеристик материалов и т.д. Тогда техническое задание будет представлять собой увесистый том страниц под тыщу, а в программе будет строк эдак тысяч двадцать.
Этого программиста-профессионала уподоблю шоферу-дальнобойщику, везущему многотонный груз за сотни километров.
Настоящая работа программиста — это работа в поле, а не написание кода в офисе.
Бесконечные командировки, дни и недели в цеху, заводоуправлении, на складе, в офисе бок о бок с инженерами, бухгалтерами, работягами, клерками – все это нужно не для составления программ (они и дома неплохо пишутся – знать бы, что писать) но для вживания. Понемногу, день за днем вникаешь в дотоле неизвестную жизнь и потихоньку ее вербализируешь. Вот в этом (а отнюдь не в знании ПИТОНа) и заключается твоя профессия – укладывать живую жизнь в строгие параграфы бизнес-правил и спецификаций.