Halt and Catch Fire - что там под капотом?

[evergreenterrace]

Warning: под катом и в комментариях - спойлеры.


Есть такая поговорка: "Тяжела и неказиста жизнь простого программиста", в которой, в общем то, есть определённая доля истины - чаще всего разработка софта (и, наверное, железа) не блещет увлекательностью и драматизмом. Кодишь от забора и до обеда, тестируешь, попутно решая те или иные возникающие проблемы. Но... Как убедительно показали создатели сериала Halt and catch fire - даже в этом скучном процессе может найтись место драме. И в каждом эпизоде они это доказывают. Итак...

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

Эпизод второй. Основных темы две - "белая комната" и коммерческая дискредитация. "Белая комната" - это единственный способ легализовать результаты обратной разработки. Суть процесса сводится к тому, что один человек реверсит, а другой, находящийся в "белой комнате" пишет код (или создаёт железо) с нуля по спецификациям, полученным от первого. Специальный посредник (адвокат) передаёт спецификации от первого второму и следит за их юридической чистотой. Таким образом потом можно доказать, что компания, ведущая такого рода разработку, не нарушила ни чьих авторских прав. Ну и FUD - грубый способ нечестной конкуренции, когда одна компания (или компании) выдавливают другую с рынка путём дискредитации её продукции, подкупа или запугивания клиентов, демпинга. В серии процесс показан слишком быстро но, таки да. Так оно происходит - заказные статьи в прессе, обзвон клиентуры, обваливание цен, фейковые судебные иски, и прочее, прочее, прочее. Хороший пример того, что чёрный пиар далеко не всегда идёт на пользу дела. Особенно, если в бизнесе немалую роль играет репутация компании.

Третий эпизод. Посвящен проблемам поиска финансирования для стартапов. Несмотря на то, что Cardiff Electric - старая компания, во второй серии она была поставлена в положения, когда вынуждена начинать бизнес с нуля. И тут было показано три основных способа поиска финансирования - венчурные фонды, знакомые толстосумы и собственные ресурсы. В итоге выбран был третий, ибо первые два не понравились либо Босворту, либо Джо. В первом случае проблема заключалась в необходимости внешнего управления и аудита, что, де-факто, передавало компанию в собственность венчурного фонда. Это было не в интересах Босворта и Кардифа. Во втором случае (с толстосумом) проблема была в том, что Джо терять контроль над тем, каким именно будет конечный результат деятельности (ибо, кто платит - тот и музыку заказывает), плюс ко всему Лулу потребовала слишком большой процент с продаж. В итоге - да, решено было обойтись собственными средствами.

Эпизод четвёртый. Страшный сон разработчика (или админа) - он что-то безвозвратно удалил (исходники, бэкапы, бухгалтерскую БД, боевой веб-сервер и т. д. и т. п.). Такое случалось с каждым, и будет ещё случаться. Ибо это можно только пережить, чтобы понять. Даже поговорка такая есть: "Админы делятся на два типа: тех, кто еще не делает бэкапы, и тех, кто уже делает бэкапы." Поговорка, написанная кровью, потом и слезами покрасневших от бессонных ночей глаз. И таки да, большинство известных мне программистов нажимают Ctrl-S не реже одного раза в пять секунд. Выработанный с годами рефлекс.

Эпизод пятый. Тема менеджмента. Кто бы что там не говорил, а программирование - процесс в большой степени творческий, и требующий соответствующей атмосферы и условий. Именно поэтому Кэм оборудовала себе берлогу - это помогало ей работать. Именно поэтому жесткая регламентация процесса, навязываемая менеджментом, нередко этот самый процесс убивает. В серии было показано типичное противостояние менеджмента и разработчиков. Хороший менеджер должен понимать, что разработчик не может всё время педалить код, что от него нельзя требовать жесткой отчётности и соблюдения всех формальностей и регламентов. Что девять беременных никогда не родят ребёнка за месяц, как бы они не старались. И самое лучшее в такой ситуации - требовать в первую очередь соблюдения сроков и качества, а не формальностей. Если менеджер этого всего не понимает - его лучше заменить более адекватным. Что и произошло.

Эпизод шестой. Last minute changes. Хорошо известный факт заключается в том, что только доведя разработку почти до финала, ты начинаешь понимать, с чего же именно стоило начинать и как делать. И в этот момент наступает нестерпимый зуд всё переписать. Ты бежишь к начальству, размахиваешь руками, брызжешь слюной строя воздушные замки и обозначая супероптимистичные сроки переработки. Хороший начальник всё это выслушает, посмотрит на календарь, скажет, что до релиза - два месяца, а еще ничего не тестировалось и отправит исправлять баги. И это в большинстве случаев - единственно правильный вариант, ибо иначе возникает ступор перфекциониста, когда работа бесконечно улучшается, а релиза всё нет и нет, сроки - профачены, клиенты растеряны и ушли к другим поставщикам. Всегда существует момент, когда надо остановиться и удовлетвориться тем результатом, а который уже есть. Бывают исключения, когда возникшая идея - это серьёзное ноу-хау, которое взорвёт рынок. Но риски более позднего старта продаж всегда должны быть адекватно оценены, и, в случае негативной оценки, переработки отодвинуты.

Эпизод седьмой. Извечный конфликт формы и содержания. Широко известный факт заключается в том, что если попросить программиста создать пользовательский интерфейс - скорее всего, этим интерфейсом сможет пользоваться только сам программист. А если то, что создаётся, рассчитывается на массового потребителя (будь то сайт, или программа, или девайс какой-нибудь), то это "что-то" должно выглядеть так, чтобы потребитель это купил. Нанимаются мега-дизайнеры, специалисты по юзабилити, изучается user expirience..., делаются макеты, прогоняются на фокус-группе, согласовываются с заказчиком (если такой имеется). А потом на всё это смотрит разработчик/схемотехник и чешет репу в размышлении - а как же он всё это реализовывать будет? Но, он же "эксперт" и легко может нарисовать семь красных линий, три из которых - прозрачные, четыре - нарисованы зелёным цветом, ну и далее по тексту. По этому берёт в руки дизайн-макет, наливает чашку кофе и начинает реализовывать все эти гениальные задумки. А потом прибегает взмыленный ПМ или дизайнер, и радостно сообщает, что концепция поменялась, и теперь всё совсем-совсем по-другому, и что клиенту просто необходима вот такая вот свисто-перделка серобурмалинового цвета, которая будет ещё и кофе заваривать...

Эпизод восьмой. Хакерство и компьютерные преступления. Как это ни странно, но информационные системы уязвимы. Они содержат ошибки, "дырки", чёрные ходы. Зачастую разработчики даже не предполагают, что от каких-то вещей надо бы защищаться. В итоге - находятся люди, которые этим пользуются в своих корыстных и не очень целях. Какое-то время их называли хакерами. Сейчас чаще используется термин "кибер-преступник". Или "кибер-воин", потому как этими же средствами можно наносить весьма ощутимый (и, зачастую, реальный) урон противнику. Иногда кого-то ловят и сажают, но такое, увы, происходит далеко не всегда. Распространяться дальше на эту тему мог бы ещё долго, но не буду. Кому интересна текущая ситуация - об этом хорошо и подробно пишут, например, на SecureList люди, которые
профессионально занимаются этими вопросами.

Эпизод девятый. О да, побеждает не тот, кто лучше, а тот, кто первый. Да, кто первый встал - того и тапки. Таковы законы конкуренции в том числе и в сфере ИТ. В ход идут любые средства. И промышленный шпионаж, и блеф, и заманухи, и многое-многое другое. Обычная дилемма проджект-менеджера (или менеджера проекта) - выпустить сырой продукт на рынок, или подождать ещё, допилить, но позволить первым выпустится конкурентам? Ставки в этом вопросе тем более растут, что победитель зачастую получает всё. Особенно, если продукт (пусть и сырой) действительно выстрелил. В сфере B2B вообще может доходить до абсурда (правда, довольно таки типичного) - продаётся то, что ещё даже не написано...

А вот именно IT-тему десятого эпизода уловить не могу. Тут тематика носит общефилософский характер.


UPD: Добавлено описание эпизодов с 7-го по 10-ый.