В мире сегодня сформировались два радикально противоположных метода организации софт-проектов: "соборный",* присущий частным компаниям и производящий преимущственно закрытый проприетарный** код, и "базарный", спонтанно возникший в сообществе OSS*** и производящий открытый и чаще всего бесплатный код. И пусть ни один из этих методов не может похвастать своим преимуществом в смысле качества и эффективности разработок, тем не менее оба выжили до сих пор, и следовательно доказали свое право на существование. Возьмем же, ребята, этот факт на заметку...
Рик Киттс в своей весьма эмоциональной реплике на artima.com признался, что он постоянно размышляет над проблемой качества кода вот уже 10 лет. "I constantly think about this", пишет он. И хоть он видит проблему только в одном из миров, проприетарном (и валит всю вину на боссов - об этом чуть позже), как нам кажется, эта проблема все же выходит за рамки бизнес моделей и присуща как "собору", так и "базару".
В самом деле, поразительный факт: жесткая иерархия, закрытость, неразглашение и прочие корпоративные традиции с одной стороны, и почти полная анархия, открытость, дух коммуны без какого либо намека на собственничество - с другой, а результат один. Плохой код, куча ошибок, заплаты, апгрейды и нескончаемая вереница проблем совместимости.
* "соборный" и "базарный" методы - намек на знаменитое эссе Эрика Реймонда "The Cathedral and the Bazaar"
** проприетарный - новое словечко в русском языке, которое уже успело просочиться в словари; от proprietary, т.е. собственнический. Проприетарный код - это когда все что вы пишите в компании, даже i = 0, является ее собственностью.
*** OSS (Open Source Software) - ПО с открытым исходным кодом. Явление, которое сейчас производит наверное больше шума, чем в начале прошлого века - коммунизм. У OSS есть свои лидеры, "Манифест", и стимул что-то делать на благо человечества, но уж никак не ради денег.
Ферма и прерии
Впрочем, всякий оптимист отметит, что хороший код существует в обоих мирах (если этот оптимист - беспристрастный оптимист), и приведет кое-какие примеры. Окей, это очень хорошо, что он, хороший код, существует, потому что этот замечательный факт даст нам шанс понять, как следует организовывать софт компании или сообщества, которые производили бы пусть открытый, пусть "широко закрытый", но хороший код.
Если не думать слишком долго, то сразу можно дать такой очевидный ответ: хорошие системы создают хорошие программисты, или великие хакеры (по Полу Грэму). Хорошо, вы заполучили такого хакера, но вы можете забыть о том, что ВХ, как всякая творческая личность, вещь капризная: с одной стороны он "в неволе не размножается", т.е. вы можете просто убить такого программиста в своей жесткой корпоративной системе, причем независимо от должности, которую он будет занимать, либо, с другой стороны, в мире OSS наш ВХ может быстро потерять интерес ввиду отсутствия денежной компенсации. Нет, нет, вовсе не потому, что ВХ любит деньги, и даже наоборот, он их презирает, ну или равнодушен, но уже не настолько молод, чтобы писать код ради самоутверждения (а ведь именно ради этого в конечном итоге создается большая часть OSS, не правда ли?).
Определенно, великим хакерам нужно что-то другое. Вероятность того, что ВХ случайно наткнется на предельно проницательного босса, каким может быть только еще один хакер, крайне мала. И с другой стороны, ВХ настолько зрелый человек, что внутренние мотивы написания бесплатного софта уже исчерпаны. Этот замечательный мозг остается за бортом.
Как вы заметили, я уже успел жестко пройтись по OSS... Все аргументы за, против, вдоль, поперек и посередке уже давно пережеваны, высказаны и перелаяны помногу раз. Проприетарный код - хорошо, потому что он создает стимул (в виде денег) для творческого созидания. Открытый код - тоже хорошо, потому что он позволяет передавать знания, обогащать их, и тем самым сохранять преемственность опыта вообще. Видите, я вовсе не дурак, и все прекрасно понимаю...
Впрочем, ребята, с годами я понимаю, что понимаю все меньше. Как это ни странно, но еще 10 лет назад я был абсолютно уверен в том, что знаю как надо писать программы. И я их писал, и был собой очень доволен. Но сегодня... Ох, я был готов расцеловать монитор, когда наткнулся на заметку Джоэла Спольски, в которой говорилось о том же самом, и теми же самыми словами. Джоэл, правда, резюмирует, что это есть признак созревания в вас настоящего программиста, но в этом я не соглашусь. Зрелость есть осознание своих неспособностей , в отличие от молодости, которая уверена в своих способностях . А раз так, то я не берусь создавать большие системы (а главная проблема именно в них): не хочу делать плохие системы, и не знаю как делать хорошие. Правда скорее всего никто этого сегодня не знает, хоть и все об этом думают. Словом, надо бояться больших систем, ребята...
Пусть же наши программы будут открытыми, ради преемственности знаний, или закрытыми в силу каких-то частных причин, но пусть эти программы будут качественными. Пусть те, кому в качестве стимула совершенно определенно нужны деньги (хотя это не обязательно означает зависимость от денег), создают проприетарные программы, а те... ладно, не будем никого обижать. Пусть кому это нравится создает открытый код. Точка. Но в итоге все мы должны быть довольны созданным. А "мы" - это и бедные юзеры тоже, между прочим.
Кафедральный базар
Окей, как говорят зажравшиеся капиталисты в старых советских фильмах, ближе к делу. То, что будет описано ниже, возможно , хотя вовсе необязательно, является моделью хорошей софт компании. А может даже и вообще, хорошей инженерной компании будущего. I constantly think about this, правда не 10 лет, а что-то около года. Тоже немало.
Начну с того, что софт-индустрия, в силу сказанного в самом начале, нуждается в неком синтезе собора и базара - мысль, наверное не такая уж сложная. Софт-индустрия должна пересмотреть свои подходы в организации труда, поскольку создание софта является процессом творческим в большей мере , чем, к примеру, создание микрочипов, и по сути сравнима в этом смысле с такими областями деятельности человека, как создание кино. И наконец, софт-индустрия, как и всякая индустрия, создает то, что покупается, и следовательно ее по крайней мере внешний "интерфейс" (если на время оставить в сторону внутреннюю организацию компаний) должен быть приспособлен к настоящей капиталистической конкуренции.
В такой идеальной компании будущего нужно определенное количество "великих хакеров", которые будут на своем месте, нужны элементы сообщества и отстутствие иерархии (или очень слабая двухуровневая система) как в OSS, и нужна атмосфера творчества, как при съемках фильма.
Утопия? Не спешите с выводами, и вместо этого давайте-ка попробуем продумать детали и доведем нашу утопию до логически завершенного состояния. И условно назовем нашу компанию "Кафедральный базар (КБ) имени собаки Павлова". Просто так, ради прикола.
Size is the king
В нашей с вами индустрии производаства ПО существует такой парадокс: проект, который по традиции должны делать (и делают) рота программистов из 50 человек, могут также сделать и 5 человек, причем за приблизительно те же сроки. В одном случае есть деньги, есть руководитель проекта, который только лишь умеет расписывать требования по 50 позициям, забивать их с помощью стандартного интервьюирования, а затем руководить проектом посредством UML и PowerPoint. Это все, что он умеет, хоть и надо отдать ему должное, он делает это хорошо. (Если не считать того, что ни его методы интервьюирования, ни его глубокие познания в UML на нашем с вами корабле уже не нужны).
В другом же случае есть от 1 до 3 великих хакеров, или программистов класса "А" или "Б" (гении и таланты, соответственно), есть тестировщик(и), и есть сборщик пакета. Дизайнеров, спецов по GUI и прочие специфические профессии добавлять по вкусу. Вся система целиком имеется в голове одного или нескольких ВХ, который видит , как надо разбить систему на достаточно независимые куски, насколько можно формализовать те или иные куски, чтобы впоследствии легче было модифицировать надстройки и даже использовать эти самые формализованные куски в других проектах (reuse, что называется). Никакой типичный руководитель не сравнится с нашим(и) ВХ в видении системы, по той простой причине, что руководитель не занимается кодированием, а ВХ все делает сам, от проектирования до реализации.
И преимущество второй схемы не только в том, что ВХ - это такой универсальный и гениальный ВХ, но также и в том, что уходит значительно меньше времени на согласование 50 различных кусков, которое так необходимо в армейской схеме с 50 солдатами. Сэкономленное на этом время, и плюс гениальные мозги ВХ, которые формализовали и оптимизировали все что в системе этому поддается - и вы получаете проект за те же сроки, что и получает наш командир роты, теоретик обобщенных подходов и PowerPoint презентаций.
Знаю, сделать заказчика счастливым сможет скорее наш майор, чем ВХ. Есть такая проблема: заказчик возвращает проект с длиннющим списком дополнительных требований. Это самая неприятная часть. Но скажу вам следующее: при сдаче проекта ВХ должен слегка поумерить свои амбиции и следовать такому правилу: можно реализовать 50% из требований заказчика (причем сделать это даже лучше, чем ожидает сам заказчик) , а остальные 50% отклонить и показать что они не нужны или уже реализованы в том или ином виде. Это вполне реально, если сделать с умом. (" Заказчик не всегда прав ", как сказал руководитель одной из крупнейших в США сетей магазинов, Best Buy).
Итак, размер компании имеет значение. Разумеется, я не имею ввиду, что компания должна состоять из 5 человек, хотя на практике бывает и такое, особенно в игровой индустрии. Вы можете иметь определенное количество крошечных взводов, как описано выше, но общий размер компании все-таки тоже имеет свой предел ввиду того, что мы в конечном итоге создаем коммуну, или сообщество программистов, а такое сообщество не может состоять из 20,000 человек. Если же наш КБ оказался таким удачливым в бизнесе, что начал разрастаться как Алиса съевшая соответствующий гриб, то следует начать разбивать компанию на более мелкие, скажем по 50-70 человек максимум, так же, как вы разбиваете большой софт-проект на более мелкие, независимые куски.
При этом все под-компании остаются под крышей одного холдинга. Есть только одно важное условие, при котором такой холдинг будет действенен: его владельцем или совладельцем должен быть великий хакер , поскольку нужен как минимум один программист (а лучше - 2-3), который видит всю картину целиком. Человек, который видит все активные проекты вплоть до деталей, и который кодирует сам - только в этом случае будет возможно удержать всю эту карусель под-компаний. И это тоже реально. Я бы сомневался, если бы не видел такого в реальной жизни.
Кодируют все!
В "Кафедральном базаре" должны кодировать все. Имейте терпение, и вы поймете почему.
Бухгалтер должен быть таким бухгалтером, который сам программирует свою финансовую систему в Excel, в отличие от типичного ленивого бухгалтера, который требует от руководства закупки какого-то финансового пакета, а потом постоянно жалуется на плохое сопровождение. Кодировать должен и VP по маркетингу: он сам организует какие-то исследования и делает программки для обработки данных. Многого для этого не нужно, просто хорошие, умные бухгалтеры и спецы по маркетингу. Представляю, как к вам придет кандидат на VPM, вы ему скажете: "у нас такое правило: кодируют все, и вы тоже будете этим заниматься", он сделает мину, или даже усмехнется, типа "еще чего"... вот тогда гоните этого кандидата в шею. Заверяю вас, он вам не нужен.
Кодировать должен и директор компании. И не в своем директорском кабинете, а там, где это делают все: либо в общем зале, если вы так устроили свой КБ, либо в отдельном кабинете специально для кодирования, если у вас все сидят в отдельных комнатах. Но никак не в директорском кабинете, который оставьте для, так сказать, посетителей музея. Конечно директор не может загружать себя в той же мере, что и остальные программисты, но запросто может хотя бы на 50%. Пусть же он возьмет на себя какие-то задачи и кодирует .
Этот принцип, что программированием занимаются все, на разных уровнях конечно, но именно все, позволит всем держать руку на пульсе всего. Как правило бухгалтер в софт-компании - это совершенно отчужденный инопланетянин, занимающийся своим (очень важным!) делом, которое никого не касается. И наоборот, его не волнует, что происходит в других отделах компании. Волей-неволей возникает отчуждение.
Отдел(ы) по маркетингу и продажам обычно тоже отчуждены: люди, которые знают рынок, и следовательно решают что имеено надо создавать для этого рынка, как правило считают себя "белыми" людьми по сравнению с программистами, занимающимися "черной" работой. Я еще не встречал такого спеца по маркетингу и/или продажам, который не смотрел бы на программиста свысока. И дело тут вовсе не в амбициях программистов и VP, а в отчуждении и всевозможных водоразделах, которые начинают возникать в компании между отделами и людьми с разными родами занятий.
Если же вы найдете для своей компании бухгалтера, VP по маркетингу и продажам, и наконец директора, которые считают программирование привилегией, и сами будут с удовольствием кодировать когда требуется, то тогда ваша компания обретет крайне редкое в наше время и ценное качество: взаимное уважение всех сотрудников друг к другу. Посему, это есть необходимое, правда недостаточное, условие создания "Кафедрального базара ": кодируют все.
Анархия - мать второго порядка
Слыхал такую историю. Еще на заре своего развития авиаиндустрия столкнулась с такой проблемой: шасси самолета начинают сильно вибрировать и даже ломаться при посадке. Крепили шасси как могли, а они все вибрируют и ломаются. Академик Келдыш предложил расслабить крепления и сделать их упругими. И что же? Вибрация исчезла.
Теперь настало время взять из мира OSS его главное достижение: анархию как модель ведения софт-проекта.
Как уже было сказано ранее, в мире софт-индустрии существует два разных подхода реализации больших проектов: либо вы создаете стандартную иерархическую схему и затем забиваете ее людьми "по резюме", или вы приглашаете нескольких великих хакеров зная, что они просто сделают то что надо. В первом случае не надо много думать, надо только иметь терпение для просмотра N * 100 резюме и интервьюирования N * 10 человек. Во втором же случае надо, во-первых, самому быть ВХ, и во-вторых иметь хорошие связи и знакомства, которые выведут вас на других ВХ.
В первой, стандартной схеме с M-уровневой иерархией вы имеете M-1 уровней, предназначенных для начальников. Откуда, как и почему возникают такие системы? Не могу ручаться за все индустрии, но именно в мире софта иерархии возникают, как это ни парадоксально, из-за неспособности большого босса вникать в детали реализации проекта. Рик Киттс, на которого мы сослались в начале статьи, предполагает, что боссы - это вообще люди, которые фактически не состоялись как программисты, и в качестве выхода из ситуации нашли себя в управлении.
Что же должен делать такой босс для того, чтобы никто не заметил его некомпетентности? Он должен создать непробиваемую стену между собой и программистами, и лучшей стеной могут стать... правильно, более мелкие начальники. А как там в самых низах иерархии, на уровне M-1, начальники будут ладить с кодировщиками - это в верхах уже никого не интересует. Хотя и для этого есть стандартные средства: PowerPoint, UML, а для обратной связи - отчеты, отчеты...
Это никуда не годится. Программистам классов "А" и "Б" меньше всего на свете нужны начальники. А больше всего на свете им нужно чувство команды и атмосфера творческого созидания - вот что им нужно.
Но если нет начальников, кто же будет принимать архитектурные решения в КБ - спросите вы? Окей, щас сделаем.
#if !defined(HIERARCHY)
#define ANARCHY
Вспомним, что каждая компания в нашем холдинге имеет небольшие размеры. Компания условно разбита на небольшие группы по 4-5 человек, каждая из которых делает отдельный большой проект, либо независимую часть гигантского проекта - не важно. Во-первых, группы эти не имеют начальников: каждая из них руководствуется теми же принципами, что и аналогичные группы в мире OSS. Людей объединяет любовь к программированию и азарт получение результата, а мелкие решения принимаются либо коллективно, либо на основе авторитета ВХ, которого должна иметь каждая группа как минимум в одном экземпляре. Заметили, что такая атмосфера исключает необходимость в начальнике и в сопутствующих атрибутах (как-то: PowerPoint и отчеты)?
Во-вторых, надо как-то решить проблему крупных вопросов архитектурного плана. Для этого вы в самом начале собираете всех сотрудников (не забудьте и бухгалтера) и объявляете о создании Совета Архитекторов, в который входят все . Вы говорите, что СА будет собираться на обсуждение архитектурных вопросов регулярно, скажем раз в неделю, и также нерегулярно, по мере надобности.
Вы также объявляете, что в Совете могут не участвовать те, кому это не интересно. Вы заметите, что на первые Советы будут приходить все, но со временем некоторая часть сотрудников поймет, что в их присутствии нет острой необходимости и просто перестанет посещать. Это будут преимущественно кодировщики, которые на самом-то деле неспособны принимать архитектурные решения, и поэтому им просто не интересно участвовать в таких дискуссиях.
И в конце концов СА сформирует сам себя без вашего участия, ну, или при минимальном вашем участии: могут потребоваться какие-то коррективы в случае, если на Совет не приходит человек, который на самом деле нужен - поговорите с ним отдельно и верните его обратно.
Главное - человек, который оказался вне Совета, не чувствует себя аутсайдером, поскольку это не начальство его исключило, а он сам. Вы сейчас скажете, что такая система не может работать стопроцентно точно, и обязательно найдутся этакие амбициозные индюки, которые все напортят... Правильно. А кто вас просил брать на работу амбициозных индюков?
#endif
У меня, ребята, есть какая-то необъяснимая уверенность в том, что это должно сработать, и более того, что это самый лучший способ организации софт-компании. Давайте-ка не отворачивайтесь и не отнекивайтесь, а прикиньте, нарисуйте эту картину у себя в голове. Поставьте себя на место программиста, великого хакера, бухгалтера, VP по маркетингу/продажам, и наконец - директора.
Стоп! Директор - это чуть ли не самая важная часть в картине, если вы уже успели додуматься. Если помните, мы сравнивали софт-проект со съемками кино... Так вот директор нашего КБ - это режиссер, и очень многое, если не все, зависит именно от него. Не то чтобы продукция или количество ошибок в ней - вовсе нет. А то, удастся ли создать атмосферу анархии, в которой все пропитано духом творчества. Может это не так-то и просто... Но, знаете ли, хорошие фильмы создают только хорошие режиссеры (кстати, обратное не истинно). Директором нашего КБ должен быть Бергман, Бунюэль или Бертолуччи, и мы будем долго и упорно его искать до тех пор, пока не найдем. А иначе игра, конечно же, не стоит свеч. В конце концов и в мире кино продюсеры и режиссеры как-то находят друг друга, и от этого выбора зависит все остальное.
***
Приблизительно раз в 3 года я меняю своего работодателя (хотя с его точки зрения это он меняет меня - хе-хе). Хожу по компаниям, прохожу интервью, собеседования, и наконец в каких-то случаях - звучит конкретная цифра, какую я ждал, или наоборот не ждал, и приглашение на работу.
Ввиду стажа работы мне могут предлагать место начальника. Признаться, я долгие годы избегал этого, но недавно снова столкнулся с этим лицом к лицу. Меня интервьюировал начальник, и спрашивал о UML и Java, и еще как бы между прочим - о PowerPoint (а какой букет, однако!). Всё. У меня лопнуло терпение, и я сказал этому человеку все, что думаю о UML, Java и PowerPoint. Забавно, что Java - это не есть инструмент начальника, но этот язык каким-то образом вписывается в традиционные иерархические схемы, за что, как мне кажется, настоящие программисты его и не любят. Этот язык был создан для начальников, а не для программистов, хотя используют-то его именно программеры...
Ну, вобщем, это все скорее личное. Я только хотел сказать, что шел по улице вот после этого интервью и думал о том, что всё не так. "Ёлки, всё везде сделано не так!". И если вы скажете, что я просто параноик, то тогда пусть эти компании, у которых я бывал на интервью, покажут мне хоть один приличный продукт. Если покажут - то я параноик.
А пока я просто ужасно недовольный и немного злой (в меру, в меру) программист, который ведет свой идиотский Блокнот.
И поскольку сказанное выше - лишь одна третья часть, ну или половина задуманного, то...
(продолжение, возможно, следует)