Низкий КПД IV

Продолжим.

Наследие. Оно же legacy. Если у меня что и вызывает прям вот искреннюю ненависть, так это ржавые наслоения древнего кода. А его надо тащить в светлое будущее, ибо это дешевле, чем переписывание заново, ну и люди пользуются, чё. Зачастую и люди не прочь съехать с какого-нибудь старого поделия / интерфейса, но у них тоже наследие, тоже пользователи и т.д. Круговая порука.
Что действительно толкового может выстроить строитель, которому 1) нельзя снести гнилой сарай, 2) нельзя увеличить здание до трёх этажей, 3) нельзя использовать бетон, 4) балки брать строго определённой марки (завод давно помер, но), 5) ничего шумного нельзя, ведь в доме живут жильцы.
Да любая задача добавления / исправления чего-либо в старом (а он уже спустя 2 года сейчас может считаться старым) софте превращается в военную операцию по спасению рядового Пупкина. Какой нафиг КПД у подобной деятельности и у результата? Все сроки и усилия умножаешь на K (K > 2), при этом всё равно на выходе получаешь караван со скоростью самого медленного верблюда.

Отсутствие идентификации. Тут смешная штука. Начну с того, что программисты сами не очень могут договориться о том, что такое программирование и кто такой программист. Есть овердофига трактовок топовых и есть триллиард трактовок индивидуальных. Соответственно, есть некоторая проблема с тем, какие задачи программисту давать, а какие не давать. Мем “тыжепрограммист[, потому ща быстро заведёшь Боинг, поставишь кластер серверов и вылечишь желтуху у алкоголика Васи]” — он не только у бабушек-соседок, отдающих утюг на починку, но и в головах многих руководителей. Потому программисты занимаются всем с разной степенью успешности. Степень нередко фиговая, тут КПД и абздольц.
Дальше проблемы с требуемым объёмом знаний и умений. В “реальном” мире есть обязательная экзаменация, есть подтверждение уровня, есть квалификационные тесты и т.п. У программистов такого нет. Без единой бумажки можешь собеседоваться на разработчика по технологиям A, B и C, ну и через 1..6 часов попасть на место. При этом часть часов будут спрашивать про X, Y и Z (так принято). И всё равно будет угадайка. Можно нанять чувака, которого хочется уволить через неделю. Можно не нанять чувака, который… например, Google отказался от автора Homebrew (скажем так, его использует половина от всех), от чего интернетики знатно забурлили, потешаясь над современным HR-процессом.
Чё в итоге? В итоге вы тратите мегатонну времени на поиск и собеседование людей. Потом мегатонну времени на то, чтобы понять, что получилось-то. Потом мегатонну на обучение. И всё равно часто не можете понять, что действительно можно давать в работу, т.к. боец зачастую раскрывается очень неожиданно.
Заставлять всех пройти сертификации? Не получится. Это дорого. Это быстро устаревает. По фундаментальным и важным штукам сертификаций нет (кроме корочки о высшем образовании, но она нынче ничего не гарантирует).
И вот какой КПД у всего этого?

Резюмирую. Если собрать всё воедино, то IT/CS индустрия в худшем своём варианте представляет собою множество случайных людей случайной квалификации, пытающихся на кое-как построенных процессах быстрее сделать (во время, свободное от посторонней фигни) глючные продукты, которые потом будут отжирать половину стоек в ДЦ (или половину вашего смартфона), а спустя год-другой превратятся в кандалы на ногах прогресса.
Но это нормально.

Finished.

Низкий КПД III

Продолжим.

Тимлиды. Довольно занятный институт. Чувак, теперь ты руководишь N людьми и проектами потому, что ты… ну, хорошо программируешь. И вообще давно у нас работаешь. Нет, нас не особо волнует, умеешь ли ты в менеджмент, в процессы, в психологию, в управление. Тыжепрограммист. Вперёд. Партия вручила флаг.
В большинстве наблюдаемых мною случаев получается какая-то фигня — из боевой обоймы выщёлкивается senior, которому приходится заниматься не тем, что он умеет делать. Всё осложняется ещё и тем, что нередко тимлида назначают, но не знают, какие точно обязанности на него навешивать. Потому тимлид в конторе ABC ни разу не равен тимлиду в конторе XYZ — первый может пару лет десяток junior’ов строить, второй может пару лет фактически быть project manager с элементами product manager.
Отдельно доставляют чуваки, которые спустя некоторое время уже не умеют в программирование на прежнем уровне, но всё ещё хотят работать руками. Бывает беда.
Почти всегда КПД тимлида в эти первые пару лет просто никакой, а влияние на процессы даже и отрицательное при особом рвении.

Непрогнозируемость результата. Попробуйте на старте разработки сервиса собрать с разработчиков прогноз того, как будет работать сервис на первой выкатке — RPS, количество ошибок, потребление ресурсов одной машинки, количество железа для отказоустойчивости. Потом сравните с реальностью. Если команда на 50% своих сервисов будет угадывать с точностью не ниже 80%, повышайте им зарплату и берегите пуще зеницы. Но такого не случится.
Проблема заключается в том, что любой сервис — конгломерат всякого от самописного кода до интеграции со сторонними поделиями. У нас нет на руках заблаговременных замеров производительности на участках сервиса. Код сначала пишется, потом замеряется. Тут и наступает момент, в который становится понятно, получилось ли уместиться хоть в приблизительное ТЗ или же ищем залежи навоза, чтобы расчистить.
Также следует учитывать тотальное непонимание заказчиками процесса разработки. Вам вполне могут воткнуть изменения перед релизом. Ну вот очень надо. Когда со мною в последний раз такое провернули дважды подряд, ушёл в другое место, ибо бестолково. Начинаете писать один продукт, заканчиваете другим. И что толку от усилий, ушедших на продумывание годной архитектуры на старте?
Мне абсолютно точно не видится этот процесс эффективным.

Некогда оптимизировать. Давайте про КПД программ. Они потребляют много памяти и процессора. Они всё равно медленно работают. То, чем раньше мог заниматься какой-нибудь забытый в углу Pentium, теперь раскатывают на десяток машин.
Если бы современный средний разработчик (команда оных, точнее) получил задачу разработать Apollo Guidance Computer, на Луну полетел бы не тот блок, что ниже на фотографии, но отдельная ракета с тележкой, на которой 2..3 тонны компьютерного железа.
Apollo Guidance Computer
Буду милосердным. Бойцы не виноваты.
Во-первых, их такими сделали. Фраза “преждевременная оптимизация — зло” годится, если умеешь своевременную. А это мало кто умеет нынче, ибо в массе ценится иное. Потому просто пишут код в надежде, что склеиваемые кирпичи сделаны хорошо (сюрприз, они тоже сделаны фигово). Авось чё получится.
Во-вторых, такой рынок. Надо быстрее, быстрее, быстрее выкинуть продукт. Пусть глючный, пусть тормозной, но надо сделать быстро! Какая тут оптимизация? Успеть бы сотню багов в первый месяц исправить. А можно и не исправлять, если гордый open source. Этим займутся те несчастные, что поспешат внедрить продукт в свой сервис. Им потом деваться некуда будет.
В-третьих, железо в тактической перспективе стоит дешевле бойцов, умеющих писать оптимальный софт. Дешевле нанять десять индусов и арендовать десять серверов, чем пару senior’ов и пару серверов. Ну и, конечно, никто не думает о том, что там пользователю дешевле или дороже, если софт ставится на железо пользователя. Один фиг планета в угаре бесконечного апгрейда. Если не сегодня, так завтра вы купите компьютер, который перестанет кряхтеть под весом нашего великого творения.
Потому оптимизировать некогда и некем. КПД массовых программ изначально стремится к нулю. Уверен, калькулятор из современных Windows или Mac OS может уложить какой-нибудь из ранних мейнфреймов, на которых погоду Земли считать умудрялись.

To be continued.

Низкий КПД II

Продолжим.

Всем плевать на стандарты. Нет, правда. Разработка породила тысячи стандартов (даже потешный на голубиную почту). Всякие RFC, ANSI, ISO, W3C, IEEE и т.д. Всем пофиг. А, ещё пофиг потому, что иные стандарты писал, кажется, Лев Толстой (1300+ страниц норм?), потому их прочтёт и поймёт только упоротый робот. А иные стоят нехилых денег, потому вы не купите их образования ради (я вот которую неделю раздумываю о покупке стандарта C++ на русском, но 5К рублей, потому лишь раздумываю).
Когда у вас в браузере поехала вёрстка, иногда виноваты не кривые лапки фронтендера, но то, что производитель (вендор) браузера на свой манер прочёл спецификацию. Если вообще прочёл.
Когда отдел QA в десятый раз возвращает сервис обратно, разработчик проклинает день, в который решил переехать с одной RDBMS на другую. Обе поддерживают стандарт SQL, но… но с нюансами.
Когда сервис внезапно падает с нечитаемой ошибкой после обновления пары пакетов, виноват иногда не бекендер, но очередной Вася, решивший, что можно стандарт трактовать и эдак. А другой Вася вообще вместо стандарта читал статью про стандарт, потому библиотека свалилась на пустом месте.
В общем, всем весело. Знаете, какую культуру разработки это породило? Культуру “какой стандарт? ничего не знаю, я так вижу”. После чего одни Васи раз за разом наступают на одни и те же грабли, а другие раз за разом воюют с тем, что в угаре наклепали первые.
КПД фронтендера, который ради одного красиво всплывающего элемента меню убивается в десяти браузерах, в которых потом так же убивается тестировщик, можете представить.
КПД бекендера, который читал стандарт и попытался написать согласно прочтённому, но столкнулся с тем, что всё упало, тоже можете представить.

Угадывание вместо планирования. Взять десять программистов, дать одну маленькую задачу и через сутки получить десять разных решений. Попросить обоснование решения и устроить перекрёстный code review — получить птичий базар, на котором каждая птица на 146% уверена в своей правоте. Это раз.
Взять десять тимлидов и попросить отреагировать на одну и ту же ситуацию — получить десять разных реакций. Попросить обосновать реакции — получить совершенно невероятные версии, которые никак не будут отвечать действительности (об этом позже). Это два.
Взять десять команд и попросить написать сервис по одному и тому же ТЗ — получить десять разных сервисов. Попросить обосновать решения — получить вообще не пойми что. Это три.
В разработке очень сложно что-либо спланировать потому, что каждый разработчик уникален. Этих существ можно как-то кластеризовать (вот это junior’ы, это наш золотой запас, а этих уволить), но спланировать их работу невозможно. Можно только угадать с некоторой долей вероятности, а потом в процессе работы палками загонять в сроки (или надеяться на то, что Вася с Петей поработают ночью).
КПД менеджеров и руководителей, пытающихся выстроить стройные и предсказуемые процессы… ожидаемо отрицательный.

Вольница. Разработчик — это драгоценность. Гений. Трепетный одуванчик. Хрустальная человеческая особь, готовая зарыдать при отсутствии печенья на кофепоинте. Пуп Земли, владеющий неисчерпаемыми запасами мнения обо всём, что есть на свете. Наверняка он лучше хирурга оперирует, лучше экономиста управляет банком, лучше космонавта космонавтит и лучше футболиста играет в футбол.
Более эгоцентричных специалистов (разве что лётчики Первой мировой) планета ещё не выпускала. Умножаем на инфантильность поколений 1990+ (а вы думали, программы вам пишут 50-летние аксакалы?), имеем развесёлые будни руководителей и кадровиков, которым надо как-то не расстраивать обидчивого зайку, не слишком давить, но и не давать спуску, вовремя подсовывать морковку и вовремя нежно охаживать по попе ватным прутиком. Иначе зайка убежит на другую лужайку, а софт кому-то писать надо.
Такой подход к трудовым ресурсам порождает отсутствие технического контроля (ты мне не доверяешь? мне? МНЕ?!) и излишнее доверие к. Разработчик не оперирует интересами компании. Разработчик не держит первым приоритетом реальные нужды сервиса. Во главе всего личный интерес. Интересно попробовать новую библиотеку (пусть Петя потом с трудом выпиливает). Интересно придумать оригинальную архитектуру (помните про Вась? вот у них всё оригинальное), чтобы потом все совсем задолбались с этим жить. Интересно убить часы на бесполезные (но громкие и очень интеллектуальные) споры. Интересно поиграть в разработку.
А вот остальное скучно. Потому Вася не пишет документацию. Не пишет тесты. Не использует типовые (aka проверенные) решения. Не читает рабочую почту. Не фиксирует свою деятельность в трекере. Не пишет админки. Не добавляет мониторинги. Не пишет логи. Возможно, и посуду не моет, не знаю — ведь это тоже скучно.
Соберите команду из N таких звёзд и попробуйте эффективно создать эффективный сервис. Если вы не разработчик и не отреагируете вовремя (ну или вам впарят под соусом “очень, очень важно и нужно”), уже через квартал в сервисе будет собственная реализация HTTP (на Rust), микроязык запросов в базу (парсер на Clojure), пара фреймворков для чего-нибудь (все другие фреймворки плохие и неправильные), ну и расхождение с ТЗ примерно на 90 градусов (разработчику виднее).
Кажется очевидным, кто КПД детского сада высоким быть не может.

To be continued.

Низкий КПД I

Совмещу в одну небольшую серию эссе всё, что надумал и написал здесь разрозненно.
Тезис: индустрия IT/CS работает с низким КПД, падающим с каждым годом. Максимальный КПД достигается при следующих условиях (всё через AND): 1) софт работает только тогда, когда надо, 2) софт занимает только те ресурсы, что требуются для выполнения задачи, 3) софт может делать и делает только то, что требуется потребителю, 4) ресурс разработки софта соразмерен задаче.
Размышления (с попытками слабо доказать) далее разбросом.

Низкий порог входа. Разработчиком может стать любой. Берёте компьютер, берёте пару учебников, ваяете пару страничек — вуаля, готов разработчик. Если дело пошло (бабушка одобрила), начинаются странички для знакомых. Потом за копеечку соседнему магазину. Потом уже какой-нибудь фриланс за рублик. Ну и дальше по пути специалистов из далёкой Индии.
Фигня в том, что творчество таких разработчиков не существует в своей отдельной галактике, но проникает в общую атмосферу. Думаю, каждый долго работающий сталкивается с ситуацией, в которой ему предлагают (до|пере)писать какой-нибудь [известный] магазин / софт учёта / что-нибудь ещё, а там адок. Начинаешь выяснять — ну конечно, писал Вася, друг директора. Как-то работало, все матерились, но в итоге устали и хотят другого.
Достаточно Васе так [успешно] поработать N лет, чтобы он утвердился в верности своей модели. Нуачё, деньги зарабатывает, даже иногда на окладе. Зачем образование? Какие курсы? Эрудиция? Парадигмы? Всё это лишнее. В мире электроники это были бы Васи, проектирующие телевизоры без малейшего знания закона Ома. Чисто на интуиции. Норм.
Так вот, софт, изготовляемый этими Васями, нарушает все мыслимые правила и соглашения. КПД у него стремится к нулю.

Многократное дублирование. Угадайте, сколько instant messengers было опубликовано после 2000-х? Не угадаете. 60+ хоть сколь известных. Мир XMPP-протокола тоже прекрасен. И всё равно список полным не является — нет Cisco Jabber и Slack, например. Что получается? Под сотню команд в мире решали одну и ту же задачу с некоторыми вариациями. Сто раз. Как минимум. Казалось бы, ну и что? Все в мире так делают. Это конкуренция и бизнес. Вон моделей автомобилей сколько.
Фигня в том, что в “реальном” мире дублирование обусловлено логистикой, стоимостью производства и местными особенностями. Чаще проще и выгоднее сделать почти такой же продукт на другом конце света, чем тащить готовый. В мире софта не так. Пусть даже одинокий пингвин на льдине сваяет утилиту, уже через час она может быть доступна как в Австралии, так и на Луне.
И так едва ли не с каждой задачей. Даже если исключить из задач чисто учебные (каждый фронтендер в жизни ваяет календарик на JavaScript, да). Даже если исключить академические (сотни языков программирования). Даже если исключить задачи know-how (поисковые движки). Исключить всякое военное, государственное и очень тайное. Всё равно окажется, что в любой момент времени в мире есть сотни людей, решающих одну и ту же задачу без заметных различий.
Как если бы доска одна, гвоздь один, а чуваков с молотками целая центурия. Ну офигеть КПД производства.

Пипл хавает. Вы же миритесь с багами? Привычно перегружаете компы. Привычно ставите другое приложение (такое же, но баги другие). Привычно равнодушно относитесь к десяткам патчей и к вечным “мы в статусе бета! это прототип!” Привычно читаете в новостях о том, как гавкнулся то один софт, то другой. Нашумевшая история с No Man’s Sky рванула только потому, что игра ну очень адово отличается от очень шумной предварительной рекламы. А так-то всё норм. Просто пацаны чуть-чуть перешагнули грань терпения.
Взять ту же MongoDB. Есличё, это одна из самых используемых NoSQL баз данных в мире (установки от соседского гаража до Microsoft и eBay). Каждый квартал появляются новости о том, как эту базу удачно атакуют и тырят данные: “Эксперты фиксируют рост числа угонов MongoDB” (2017), “Разработчики MongoDB «немного расстроены» из-за множества утечек данных” (2016), “Десятки тысяч баз MongoDB доступны через интернет” (2015). Секрет успеха — берёте Васю из первого пункта этого эссе, просите поставить MongoDB (которая by default великолепна), ждёте наплыва интересующихся.
Хотите посмотреть, сколько фич добавляют и ошибок исправляют ежемесячно в этой базе? Смотрите: в среднем 100+ в месяц только в core server. Свежая версия 3.5.2 получила 200 issues в changelog.
Давайте ещё раз. Ну вот для осознания. База данных мирового масштаба популярности хреновая настолько, что в ней уже который год в каждом месячном релизе находят десятки ошибок. И в этой фигне многие организации хранят ваши мимимишные данные.
КПД подобных штук… ну… впрочем, мы все привыкли к патчам Windows, потому всё хорошо. Вы всё равно поставите этот софт. Потому никто не будет делать его качественным. Его будут делать быстро до тех пор, пока вас это устраивает. А вас устраивает.

Разработчики тоже хавают. Если думаете, что страдает только простой народ, ошибаетесь. Разработчики страдают больше. Народ-то видит только верхнюю часть айсберга, но не фейспалмит от десятка глючных и тормозных библиотек, которые к этому айсбергу приходится прикручивать.
Но и это норма. Все привыкли к тому, что приходится пользоваться фигнёй. Мне в этом контексте нравится недавняя история: “Миллион строк в секунду из Postgres с помощью Python”. Кратко так: самый популярный драйвер на одном из самых популярных языков программирования к одной из самых популярных RDBMS годами представляет собою архитектурное убожество. Пришли пацаны, которых это настолько утомило, что написали свой драйвер, работающий в среднем в три раза быстрее. В три раза, Карл.
Любой софт, что сложнее ложки, состоит из множества таких библиотек. Почти любой софт, что сейчас “промышленно” производится, может работать гораздо быстрее и потреблять гораздо меньше ресурсов. Если разработчики хотят и могут. Но они не хотят и не могут. Часто просто не умеют.
Мы привыкли относиться к такой фигне… скажем, с пониманием и коллегиально. Ни у кого нет времени всерьёз переписывать какую-нибудь ужасающую поделку. И кто без греха? Вот ты, Иванов, чего такой критикан? Сам без багов пишешь? Нет? Ну и помолчи тогда. Бери эту нелепую каку и гвоздями с изолентой приматывай к продукту.
Лично (как живьём, так и в переписке) знаком с десятками разработчиков, которые считают эту ситуацию нормой. Ну т.е. хотелось бы лучше, но и так сойдёт. Нет никаких безусловных профессиональных ритуалов (типа клятвы Гиппократа или присяги), диктующих программировать качественно и клеймить бракоделов. Мы не клеймим, мы относимся с пониманием. В конце концов, никто не заплатит за тысячи часов, что потратятся на переписывание после стотысячного Васи. А кушать хочется.
Разработчики хавают, КПД же софта из такого гуано и веточек… и так сойдёт, ага.

To be continued.