Низкий КПД 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.

Добавить комментарий