Хмурый Техлид

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

Перелистывая старые страницы Вчера умер Фредерик Брукс - инженер, известный многим специалистам по программированию по книге “Мифический человеко-месяц”. Книга эта не нова - написана она была в 1975 году по следам работы Брукса в IBM, где он, в частности, руководил разработкой мейнфреймов System/360 и операционной системы для них OS/360. Кстати, именно он ввел в обиход термин “архитектура компьютера”. Произведение вносилось в различные списки важных произведений в области разработки ПО, хотя сейчас, конечно, новаторскими идеи, изложенные там, уже не назовешь. Просто потому, что они уже глубоко проникли во многие методы управлением инженерии программ и не кажутся чем-то необычным. Тем не менее, неплохо вспомнить некоторые из них и тем самым помянуть Фредерика Брукса, по книгам которого мы учились управлять хаосом. Многие из этих идей мы все знаем и не подозреваем, что они были впервые упомянуты именно в “Мифическом человеко-месяце”. Если у вас есть некоторая программа, то нужно в три раза больше начальных усилий, чтобы превратить ее в программный продукт - написать документацию, обеспечить сопровождение и так далее. Точно так же, нужно в три раза больше усилий, чтобы сделать эту программу расширяемой и назвать ее программным комплексом - сделать понятные API, точки расширения и так далее. Если же нужно и то, и другое, то это системный программный продукт, и его создание стоит в 10 раз больше, чем написание просто программы. Если программный проект отстает от расписания, то добавление к нему людей только еще больше задержит его. Связано это с тем, что инженерное дело - работа творческая и сложная, и подключение новых людей требует их обучения, причем обучать будут те, кто уже работает над проектом. Т.е. и новые люди еще толком ничего не делают, и старые отвлекаются. Кроме того, многие задачи легко не параллелятся - цитируя книгу, “чтобы родить ребенка, надо 9 месяцев, сколько женщин к этому не подключи”. Производительность сильных и слабых инженеров с похожим опытом и зарплатой может отличаться в десять и больше раз. К этому сложно что-то добавить. Это применимо и к командам - сильные и слабые команды по выхлопу тоже могут отличаться на порядок легко. Повторю - с похожим опытом и зарплатой. Т.е. это не про сравнением сеньора и джуна. Это снова подчеркивает важность качественного найма и своевременных увольнений - без этого поддерживать высокий уровень команды сложно. “Эффект второй системы” - если вы занимаетесь разработкой новой версии системы, которую создавали раньше, то будьте осторожны и не начните впихивать в дизайн разного рода фантазии. Нередко такой “архитектор с опытом” решает, что теперь он досконально знает требования и сможет разработать отличный дизайн, который позволит эти и будущие требования удовлетворить. Часто это заканчивается тем, что этот техлид оказывается в плену своих старых взглядов и ограничений и не может адекватно оценить изменившиеся реалии, где новая версия системы должна быть другой, а не совершенной. Готовьтесь выбросить прототип / начальную реализацию системы. В этой главе Фредерик пишет, что часто команды пытаются превратить в полноценную программу самую первую ее версию, и это ошибка, потому что единственное назначение этой версии - это проверка гипотез и получение опыта. То есть, нельзя дом из говна и палок превратить в дом, который долго простоит. Его надо разрушить и построить заново. “Постоянны только изменения” - хорошая фраза из той главы. Отставание от графика всегда происходит постепенно. Никакой проект не отстает сразу на год - это происходит через “блин, сегодня не успел, но завтра точно будет” раз за разом.. Чтобы избежать этого, цели должны быть атомарными - либо сделано, либо нет. “Готово на 90%” не подходит и будет самообманом. Также этапы должны быть короткими - несколько недель, не больше. Серебряной пули нет. Никакие отдельно взятые методика или инструмент не позволят ускорить разработку ПО в десятки раз. Комплекс мер и знаний на протяжении многих лет - возможно. Спи спокойно, Фредерик. Ты нас многому научил.

О делегировании. Первое правило делегирования: то, что нравится делать, скорее всего надо делегировать. Следствие: успешное делегирование - это когда делаешь только то, что не нравится. Это, конечно, шутка, но лишь частично. Рост технического лидера / руководителя подразумевает выход из зоны комфорта. Я не говорю про "не нравится" в смысле ненависти к своей работе - это, очевидно, нездоровая штука. Я про напряжение развития, как в спортзале. И в технических проектах это прежде всего про работу, которую кроме лидера вряд ли кто-то еще в команде сделает. Например, когда вся команда пишет код или что-то интересно дебажит, техлиду лучше заняться чем-то, что является более определяющим для проекта - планирование и расстановка приоритетов, изучение метрик и их трендов, обновление документации в важных местах типа API, прямое общение с пользователями, инспекция и улучшение процессов, найм и увольнение и так далее. Работа лидера - делать то, что сделает команду более эффективной, увеличит ее производительность и даст ей смысл на месяцы вперед. Все прочее можно и нужно делегировать.