Блог yukon

Регистрация

Календарь

<< Сентябрь 2011  

Пн Вт Ср Чт Пт Сб Вс
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Теги

doc love  fun  анатомия подсознания  афоризмы  джоэль спольски  наука и жизнь  письма феминистки  психология  саморазвитие  системное мышление  фильмы 

На странице

RSS - подписка

1|2|3|4

Утилитарный программист (перевод статьи Джоэля Спольски)

 

Ссылка

Утилитарный программист

 

Джоэль Спольски
Среда, 23 сентября 2009 года

Джемми Завински (Jamie Zawinski) – это тот, кого я бы называл «утилитарным программистом». (Duct Tape Programmer) И я скажу это с большой долей уважения. Он представляет собой разновидность программиста, который усердно трудится над построением будущего, и делает полезные вещи так, чтобы остальные люди могли заняться другими вещами. Он является тем парнем, которого вы хотите заполучить в свою команду по постройке картингов, потому что у него есть два любимых инструмента – изолента и WD-40. И он изящно орудует ими, даже если ваш картинг несется вниз по склону со скоростью одна миля в минуту. Это происходит в то время, когда другие программисты до сих пор находятся в начальной стадии спора о том, стоит ли использовать титан или некоторые виды композитных аэрокосмических материалов, которые Боинг применял для своей модели 787 Дримлайнер.
Когда вы закончите, у вас, возможно, будет грязный картинг, но я абсолютно уверен, что он будет летать.
Я только что прочитал интервью с Джемми в книге «Программисты за работой», Питера Сибеля. Идите и купите её прямо сейчас. Это отличный набор интервью с рядом великих программистов, включая Питера Норвига, Гая Стила, и Дональда Кнута. Эта книга настолько интересна, что я потратил вчера 60 минут на беговой дорожке вместо обычных 30, потому что я не мог оторваться от чтения. Как я уже сказал, идите и купите её.

Идите! Я подожду.

Здесь написано, почему мне нравятся утилитарные программисты. Иногда, когда вы работаете в команде, и вы заняты набиванием кода, кто-то подходит к вашему столу, с кофейной чашкой в руке, и начинает нудить о том, что если вы будете использовать многопоточные компоненты COM, ваше приложение станет на 34% шустрее, и это совсем даже нетрудно, потому что он написал кучу шаблонов, и всё, что вам остаётся сделать – это отнаследоваться от его 17 шаблонов, примерно по 4 аргумента в каждом, и вам всего лишь надо будет написать тело функции.

Это просто огромный лист множественного наследования от разных классов, и эй, presto, многопоточный COM. И ваш взгляд затуманивается, и у вас нет ни одной чёртовой идеи, о чём этот чудак рассуждает, но он просто не хочет уходить, и, если даже он уйдёт, он просто вернётся в свой кабинет написать ещё больше своих классных классов, полностью собираемых из шаблонов множественным наследованием, без единого куска настоящего кода реализации, и это, похоже, будет виснуть по-черному, так что вы собираетесь записаться в ночную смену, чтобы прийти и попытаться разобраться с этим, потому что он будет на одном из чёртовых сборищ «Шаблонов проектирования».

А «утилитарный программист» не боится сказать: «Множественное наследование – хрень собачья. Прекрати это. Просто прекрати».
Видите, все остальные слишком боятся выглядеть глупыми, из-за того, что они просто не могут одновременно удержать достаточно фактов в своих головах, чтобы делать множественное наследование, или шаблоны, или COM, или многопоточность, или любую другую хренову работу. Так что они робко следуют за мимолётными программистскими поветриями, которые снисходят от астронавтов архитектуры, вещающих на конференциях и пишущих книги и статьи, и которые настолько более умнее, чем мы, что не могут понять, что их хрень, которую они продвигают, слишком сложна для нас.

Здесь то, что Завински сказал о Netscape – «Это было решение подобно отказу от использования C++ и не применять потоки, которое позволило нам поставить продукт вовремя».
Позже, он написал почтового клиента для Netscape, но команда, которая отвечала за правильный показ сообщения, так и не поставила свой компонент. «Это был просто большой пустой прямоугольник в центре окна, где мы могли бы просто показывать обыкновенный текст. Они были чрезвычайно академичного мнения о своём проекте. Они пытались достичь этого с помощью DOM\DTD… “О, ну, что нам нужно сделать, так это добавить ещё один уровень абстракции здесь, и иметь делегата для этого делегата того делегата. И в результате символы появятся на экране.»
Питер спросил Завински: «Чрезмерный инжиниринг, похоже, здорово раздражает вас?»
«Да», ответил тот, «В конце дня, сделайте эту чертову штуку! Было бы здорово переписать ваш код и сделать его яснее и с третьего раза он действительно станет классным. Но это не главное – вы здесь не для того, чтобы писать код; вы для того, чтобы поставлять продукт».
Мой герой.

Завински не делал много тестовых примеров. Они «звучат здорово в принципе. Если применять их при неспешном темпе разработки, так это точно то, что надо. Но, когда вы слышите: «Мы должны сделать это с нуля за шесть недель», то, я не могу сделать это, пока не от чего-либо не откажусь. И то, что я собираюсь выкинуть, так это то, что не является абсолютно критичным. Если там не будет тестовых примеров, заказчик не будет на это жаловаться» .
Перед тем, как вы пуститесь во все тяжкие, вспомните, что Завински работал в Netscape, когда они переворачивали мир. Они думали, что у них есть только несколько месяцев до того, как кто-то другой придет и отнимет их кусок хлеба. И масса важного кода написана подобным образом.
Утилитарные программисты – прагматики. Завински популяризировал рецепт Ричарда Габриэля – «Хуже – это лучше». На 50%-хорошее решение, , при помощи которого люди реально решают больше проблем и переживет 99-процентное решение, которое ни у кого нет, потому что оно до сих пор в вашей лаборатории, где вы ее бесконечно вылизываете.
Поставка – это опция. Действительно важная опция. Ваш продукт должен ее включать в себя.
Один принцип, которые утилитарные программисты хорошо понимают, это то, что любая разновидность техники кодирования, которая хоть чуть-чуть сложнее предыдущей, может оказаться роковой для вашего проекта. Утилитарные программисты стремятся избегать C++, шаблонов, множественного наследования, многопоточности, COM, CORBA, и кучу других технологий, которые очень даже резонны, когда вы думаете над ними долго и упорно, но они, честно говоря, просто слегка сложны для человеческого мозга.

Конечно, формально нет ничего плохого в том, чтобы пытаться написать многопоточный код на C++ под Windows с применением COM. Но это чревато таким катастрофическими багами, которые случаются только в очень специфических случаях, потому что наши мозги, честно говоря, не очень хороши для написания такого рода кода.

Обыкновенные программисты, откровенно говоря, отстаивают это, и не хотят признавать то, что они не способны написать этот суперсложный код, и они позволяют задирам из их команды отвлекать их каким-то Богом забытым архитектурным шаблоном на C++, а иначе, им бы пришлось признаться в том, что они просто не считают себя достаточно умными использовать то, что было бы превосходной техникой программирования ДЛЯ СПОКА (героя сериала «Звездный Путь»). Утилитарных программистов  не заботит, что вы думаете о них. Они используют простые основные инструменты и напрягают мозги для того, чтобы эти инструменты позволили им писать более полезные вещи для их заказчиков.

Однако, одну вещь вы должны иметь в виду – то, что утилитарные программисты в программистском мире представляют собой эквивалент симпатичных парней…
таких фантастически красивых молодых людей, которые могут валяться на кровати, небритые, непричесанные, с нечищеными зубами, и входить в метро во вчерашних мятых брюках и выглядеть прекрасно, просто потому, что они такие.
Вы, мой друг, не можете выйти в люди непричесанным. Потому, что вы просто не так красивы. Утилитарные программисты должны обладать немалым талантом, чтобы отбросить эти ухищрения. Они должны быть достаточно хороши, чтобы поставлять код, и чтобы мы прощали им то, что они никогда не пишут тестовые примеры, или если они объединяют указатели «вперед» и «назад» в своем связанном списке в одно двойное слово, чтобы сэкономить 32 бита, потому что они достаточно хороши и умны, чтобы им это удавалось.
Вы еще не купили «Программисты за работой»? Идите! Это была всего лишь первая глава!

 

 

Теги: джоэль спольски

Мысли по курсу Doc Love

 

Док Лав, на первый взгляд, дает 100% правильные и успешные советы. Он справедливо считает, что женщинам нравятся уверенные в себе и интересные мужчины.

 

Но он не учит, как стать такими, он учит, как ими казаться. Кроме того, он требует беспрекословного подчинения своей «Системе» и своим советам. Возможно, следуя его советам, можно на время создать иллюзию уверенного и интересного мужчины, но у женщин, как он сам признает, есть шестое чувство, и рано или поздно они все равно распознают фальшь. 

 

Поэтому — сказка ложь, да в ней намек — надо читать его систему, и из нее стараться понять, как мыслят женщины, и что на них действует, но нужно не только и не столько следовать наставлениям Док Лава о том, как себя вести, сколько воспитывать себя в таком духе, чтобы эти действия шли изнутри тебя самого, а не следуя его или чьим-то советам. 

 

Не будешь ведь всю жизнь писать ему письма с вопросами «Шеф, все пропало, она уходит, шо мне делать?!!!» или лихорадочно вспоминать, что говорится в Системе по этому поводу. :-) 

 

 

 

Теги: doc love

Кикнуть заигноренного (Kicking the Llama)

Kicking the Llama


October 10th, 2003 by Kevin Cheng :: see related comic


 Пиная ламу


 Кевин Чен, 10 октября 2003 года 


Джоэль Спольски – известный разработчик ПО, который пишет на своем веб-сайте материалы, описывающие разработку ПО от проектирования интерфейса до управления проектом. Недавно он опубликовал книгу, где собрал свои статьи, написанные в последние несколько лет. В этой книге, озаглавленной как «Разработка пользовательского интерфейса для программистов», обсуждается, как программистам следует перестать бояться разработки пользовательского интерфейса (UI) и подчеркиваются некоторые направления и правила для демистификации проектирования UI.


                 Как бывший разработчик ПО, ставший консультантом по взаимодействие человека и компьютера  - Human-Computer Interaction (HCI), и тот, кто работал в течение ряда лет в индустрии ПО с массой программистских архетипов, я проработал эту книгу и, что более важно, отобрал то, что я прочитал и что является в этой области особенно значимым.


                 Джоэль начинает с описания концепции контроля, и ее важности для восприятия пользователи и, окончательно, возможных разочарований. В особенности, он упоминает важность совпадения модели пользователя с моделью программы, приводящую к его аксиоме:


 Пользовательский интерфейс является хорошо спроектированным, когда программа ведет себя именно так, как она должна вести себя в представлении пользователя. 


В то время, как аналогия автора с его бывшей работой в пекарне является не очень значимой, пример все-таки иллюстрирует важность контроля на эмоциональное состояние пользователя. Далее он обсуждает предоставление пользователям ощущение контроля с помощью проектирования пользовательской модели. Определение концепции «программной модели» и «пользовательской модели» для своей целевой аудитории программистов, является, как мы надеемся, шагом к созданию лучшего UI; по меньшей мере, это приведет к появлению более информированных разработчиков.  Моей единственной претензией было что определения автора слишком краткие. Как показывают сегодня наши комиксы, пользовательская модель не является идентичной для всех, особенно для программистов.


 


Я не думаю, что его статьи приведут к внезапному наплыву сонма пользовательских интерфейсов, вдохновленных программистами. Его статьи зачастую обсуждают процесс разработки, выбор платформы и другие технические вопросы. По сути дела, его аудитория не ограничена сектой программистов, уверовавших в хороший дизайн UI. Так что, его книга и статьи могут просто информировать непосвященных по вопросам UI и облегчать взаимодействие с программиста со специалистами по HCI.


 


Эта книга может помочь программистам создать свой собственный UI, когда у них нет доступа к консультантам по HCI, но что же они будут делать? Как книга, подобная этой, повлияет на взаимодействие между HCI и программистами в целом? Давайте во-первых, взглянем на программистов в общем.


 


                Из моего опыта, существует четыре основных класса проблемных программистов, с которыми мне приходилось работать:



  • Энтузиаст: те, кто стремится идти на поводу требований HCI. Эти разработчики с удовольствием работают над сложными задачами, но любят иногда тратить слишком много времени на вылизывание несущественных аспектов UI;

  • Угадывальщик: те, кто ничего не понимает, но считает себя полностью компетентным и разрабатывает совершенно непригодные вещи до тех пор, пока не станет слишком поздно, чтобы что-то изменить;

  • Нильсен: те, кто постоянно цитируют правила юзабилити из Норманна, Нильсена или даже Джоэля Спольски, чтобы оспорить решения по UI;

  • Напуганные: те, кто тратит больше времени на споры, насколько трудно будет сделать задачу, чем на время, которое бы потребовалось на действительное выполнение задачи. Их первой линией обороны является попытка так изменить требования, чтобы они совпали с их программной моделью, вместо того, чтобы взяться за работу над задачей. Вы уже начинаете думать, что они боятся любого UI.


 


                Конечно, существуют исключения этих утрированных обобщений, варианты, которые являются их смешением. Испуганный Нильсен особенно распространенный тип. В большинстве типичных классов я находил Угадывальщика.  Наименее типичным является Энтузиаст.


 


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


 


                Управление Угадывальщиками является проблемой регулярно общиения с ними, чтобы быть уверенным в том, что они понимают требования правильно. Ответственность лежит на обеих сторонах; программисты должны задавать вопросы при любом намеке на двусмысленность, а HCI должны регулярно выполнять то, что я называю «Читать UI код». Точно так же программисты убеждаются в правильности своего архитектурного дизайна через чтение кода, они могут убедиться в правильности реализации UI вместе с HCI.


 


                Предполагая, что программисты являются логическими существами (что есть большое предположение), хороший HCI специалист может обосновать свои причины нарушения правил жалующимся адвокатам Нильсена и, в случае необходимости, обосновать причину того, что правило неприменимо в данной ситуации. Я бы мог пойти дальше, рассказав, что я никогда не увижу, чтобы это подошло к выбору алгоритма программистом, но это в другой раз.


 


И, наконец, Напуганный – вероятно, он наиболее опасный член команды. Проблема с Напуганным состоит в том, что его приоритетом является программная модель. Говоря терминами Джоэля, программная модель превалирует над всем другим. Если вы требуете выпадающее меню, отсортированное особенным способом, Напуганный может объяснить, что это просто не может быть сделано вследствие структуры базы данных. Давайте забудем на минутку, что база данных должна быть разработана в соответствии с требованиями UI. В конце концов, многие проекты растут, имея дело с устаревшими артефактами, доставшимися по наследству. Решение состоит в коммуникации – с чем? Здесь риск заключается в неспособности HIC специалиста разоблачить отговорки программиста. Если бы я не был техническим специалистом, я бы должен был принять на веру слова Напуганного и таким образом, приспособить свои требования, вместо того чтобы оспорить его отговорки.


 


На самом деле, работать с любым из этих программистов трудно, если вы не являетесь технически подкованным. Угадыватель неправильно интерпретирует требования по большей части потому, что дизайнер говорит на разном с ним языке. Энтузиасты имеют сложности с теми опциями, которые технически трудно реализовать, в то время как HCI специалисты часто оказывают медвежью услугу, настаивая на том, что эти требования жизненно необходимы для юзабилити.


 


HCI консультант мог бы облегчить такие переговоры, если бы он был технически подкованным, хотя, с другой стороны, разработчикам легче понять базовые концепции UI, чем дизайнеру изучить нотацию «Большого-О»; что возвращает нас опять к Джоэлю.


 


                Коммуникационные барьеры между HCI и программистами является причиной всех результатов, в зависимости от типа программистов, с которыми вы работаете. Понижение этих барьеров будет содействовать более ясной коммуникации, которая приведет к меньшему недопониманию. Большинство брешей, которые мы обнаруживаем, решаются таким способом.


 


                Возможно, лучшее полное взаимопонимание между разработчиками поможет в этой коммуникации.


 


                Я оставлю вас поразмышлять об архетипе Нильсена. Целевая аудитория Джоэля довольно малознакома с UI, так что его книга является все-таки вводной. Есть несколько, если это возможно, заслуживающих внимание «правил», которых еще не касались ранее. Однако, утверждая набор правил и аксиом для программистов, он несет довольно большой риск. Программисты изначально имеют логический склад ума. Особенно, цифровая логика является областью, где они работают и в терминах которой они думают. Есть 1 и есть 0, и редко – что-то между ними. Так что, когда утверждение представлено как правило, оно может быть понято слишком буквально.


 


                Читая другие статьи Джоэля, я понял, что он не собирался предоставлять в них много жестких и быстрых правил как способ обучения разработчиков. Его книга может рассматриваться как набор общих указаний для формирования структуры мышления. Единственная выгода от правил, цитируемых программистами типа «Нильсен», состоит в том, что они, возможно, представляют санитарный кордон для HCI. Дизайнеры определенно не являются безупречными и у нас редко есть второй HCI специалист, чтобы получить обратную связь. Оставленные наедине с нашими устройствами, мы часто совершаем ошибки и несогласованные действия. Я советую разработчикам правила, которые они взяли на сайте Джоэля, на сайте Джейкоба, на UIE или где-то еще, применять как общие указания и предоставить нам механизм рациональной обратной связи.


ШЯРРРр



 



 


 


22 Responses to “Kicking the Llama”


 


Mike wrote: 10 Oct 2003


 


Hahah… Being an ex-dev myself, I can totally relate to this week’s strip. While wearing the hat of a software dev., we often get into the thinking of more feature shown is better and end up plastering UI with everything we can think of.


 


isomorphism wrote: 15 Oct 2003


 


Ok? Cancel?


 


Userinterface design is a pretty hot topic, for at least many years now. What I didn’t know was that someone could actually make a comic out of this and make sensible comments about UI design!


 


Roland Tanglao's Weblog wrote: 15 Oct 2003


 


4 types of problematic programmers for UI design


 


(SOURCE:”joel”)- Very true and very funny because I have worked with all four types.


Wayne wrote: 15 Oct 2003


 


Nice article, thanks.


 


At the risk of being both negative and off topic, the site formatting you’ve chosen makes it difficult to read.


 


For those of us with high-resolution monitors, the text is very small. That’d be forgivable if we could increase the text size in our browsers, but it seems it’s fixed for your pages. I have good vision, so I’d hate to think what you are putting a person with a visual-impairment through.


 


The dark-grey text on light-grey background doesn’t help either.


 


Normally I wouldn’t bother mentioning this, but as you are HCI-dudes, I thought it useful.


thegoodtomchi wrote: 15 Oct 2003


 


Thanks for the comments Wayne. We’ll look into editing our styles so that text resizing works. It will be another triumphant victory for user feedback!


Mal Ross wrote: 15 Oct 2003


 


First time on the site and what a great article to start with. 


 


One thing puzzles me, though — kicking the llama?


Eric wrote: 15 Oct 2003


 


Wayne, I don’t know if you’re familiar with it, but Mozilla Firebird (http://www.mozilla.org/products/firebird/) (and probably Mozilla proper) resize the text just fine (as well as being good browsers in their own right).


 


I’m not sure it’s true that programmers are inherently binary in their choices. Maybe a beginning programmer is, but any experienced software developer should be quite familiar with design tradeoffs; often one particular design pattern or algorithm can’t be identified as an unqualified best. I would think most reasonably intelligent people could see the analogy to HCI rules. On the other hand I may be giving people too much credit; I’ve seen fellow developers redesign a progress bar so that it merely increments itself every x seconds (and restarts from 0 when it hits 100%) instead of actually tracking progress because it “looked better”.


 


Still, I think getting more people aware of HCI and UI design is a Good Thing; the fewer QuickTimes and RealPlayers we have, the better.


Eric wrote: 15 Oct 2003


 


Oh, and Mal, I think the title refers to Winamp, whose mascot is a llama and whose motto is “it really whips the llama’s ass”. I gather Kevin is not particularly fond of Winamp’s interface design.


mp wrote: 15 Oct 2003


 


Another class of problematic programmers:


 


Those that can’t stand what they see


as stupidity. If you were to face


the facts, some HCI people are, let’s


say, less than perfect. Also they tend to


be very political creatures — if someone


in upper management likes a particular


feature even if no customer is going


to need it and it is going to be staring


all customers in the face 24x7 and


it takes up valuable screen real estate —


the HCI guy is going to put his


full weight behind it anyway.


Of course the HCI guy is going to


see the programmers who oppose


his politically expedient issues


as “problem” probrammers!


brethorsting wrote: 15 Oct 2003


 


winamp skins for dummies


 


I just found a new comic strip through joelonsoftware. I’ve always absolutely, completely detested User Friendly. I have never found it to be funny or interesting in any sense. However, I think that OK/Cancel is actually really quite amusing, and…


aaron brethorst wrote: 15 Oct 2003


 


you guys really should open comments and trackbacks on the comic strip itself. I notice that the number of comments/trackbacks for the first blog entry under a strip are significantly higher than they are for the second one. This suggests to me that most people are just plugging the first trackback URL they find, regardless of whether they’re attempting to do a trackback on a strip, or on an actual entry.


cheers 


Developer wrote: 15 Oct 2003


 


I’d like to take issue with the tone of this article, represented nicely by this quote:


 


“Programmers are inherently logic oriented. In particular, digital logic is the domain they work and think in. There are 1s and there are 0s and rarely anything in between.”


 


I think that’s a pretty narrow minded and dehumanizing generalization.


 


Many people react to disagreements by dismissing the concerns of others as mental defects of their “kind”. This problem is particularly endemic to the software world, where people identify so closely with their cliques.


 


I think that it’s really unfortunate when people think about and communicate with their coworkers in this way.


Tom Chi wrote: 15 Oct 2003


 


Well we’re sorry if the tone of the article offended you. There is nothing wrong with being logical, in fact, it’s something that many people (both developer and non) pride themselves on. If it sounds like a mental defect, then that is not the intention, as both KC and I are reasonably logical people.


 


That said, what the article tries to do is intiate a dialogue between developers and HCI folks. In most organizations it is the HCI person who is dismissed as “their kind”, and rarely understood (if for nothing else than their small numbers compared to developers). That the article would put developers on the defensive is already surprising to me. KC is describing his own experience, and if you have other experiences which have helped you avoid these very common communication problems, then we’d definitely welcome them.


stanley chong wrote: 16 Oct 2003


 


Hi,


not that this has anything to do with your above article, but it’s really an eye strain to read your blog as there is little contrast between the font color and background color.


Ben Poole wrote: 16 Oct 2003


 


WinAmp has a DESIGNED INTERFACE? 


mr. hu wrote: 17 Oct 2003


 


I agree with the above poster. Programmers are not DSP chips. most of us rarely run into binary anything, and get nervous when talking about stuff in base 16.


 


Programming is every bit as creative as any other “creative” endeavor. we just don’t go to art school.


Kevin Cheng wrote: 18 Oct 2003


 


I absolutely agree, programming is an incredibly creative endeavour. However, the machine you’re working on IS a set of chips and gates and a programmer’s problem solving skills involve creatively manipulating this logic. Their DOMAIN is logic and they’re GOOD AT IT.


 


I believe the quote “Developer” quoted above is a little out of context, too. I was referring to the risk of Nielsen type programmers who interpret and apply rules too literally. Not all programmers are this way and in fact, most aren’t but the kind of programmer I describe does exist and I’ve experienced several even in smaller firms.


Vernell wrote: 18 Oct 2003


 


Just out of curiosity, does anyone know of any major or minor software products that are great examples of HCI design done right?


Jamie Fristrom wrote: 21 Oct 2003


 


I consider myself a “fearful” and I wear the name as a badge of pride. Fearfuls are simply more likely to ship on time. We may be confused with “lazies”, which is annoying.


Here’s how to deal with us:


* Ask us what it would take to get the feature done. Time / personnel / etc. Remind us that with computers, nothing’s impossible. Ask for best-case and worst-case estimates.


* Is there enough slack in the schedule to accomodate it? If not, decide what features to cut to accomodate it. Or admit that, yes, this feature is not in fact worth it.


Kevin Cheng wrote: 21 Oct 2003


 


I will happily admit that certain features are not worth the time it takes to implement them.


 


I don’t believe anyone that says, “that’s going to take too long to do in the current architecture” is automatically a Fearful. Rather, those that do so as the FIRST RESORT rather than the last are what I would call Fearful. Rather than taking it as another requirement which needs to be implemented, some programmers almost instinctively resist when another 15 minutes of thought might actually find a reasonable approach. Having a technical background myself, I’ve sometimes found that I had to personally walk them through their reasoning and find that alternate path myself. Something HCIers should not be expected to be have to do nor be able to do it.


 


Having said all that, I’m simply clarifying my definition, what you said in terms of process I completely agree with. It’s a question of the attitude more than the actions that make someone a Fearful.


oa wrote: 5 Nov 2003


 


came here to read the Joel book review, then complain about the font size (Mozilla resizes it fine, but why would a HCI site use a non-readable font by default?), but actually I have to comment on the “programmer kind” thing, no matter how off-topic.


 


mr. hu: I firmly believe that to be a good programmer, you need to understand the platform. To understand the platform, you have to understand how computers work in general, and that DOES mean you need to be able to work with binary. So, if you’re nervous about it, I think you need to train more.


 


Besides, DSP chips these days use floating point and are better at “fuzzy logic” than most programmers.


Fred Swartz wrote: 8 Feb 2007


 


Your basic points are good, but the characterization of programmers is surprisingly off the mark for programmers I know. You might recognize the offensive characterization when it’s flipped around:


 


Graphic designers are inherently illogical. In particular, they think and work in an analog domain where things are rarely 1 or 0. Thus, when a statement is presented as a rule, they may not be able to understand and follow it.


 


 

Как стать менеджером ПО? (How to be a program manager)

How to be a program manager


by Joel Spolsky


Monday, March 09, 2009


 


http://www.joelonsoftware.com/items/2009/03/09.html


 


Как стать Program Manager?


 


Джоэль Спольски, Понедельник, 9 марта 2009 года


 


Наличие хорошего менеджера ПО (Program manager — PM) – одна из секретных формул разработки по-настоящему выдающегося программного обеспечения. И в вашей команде, вероятно, таковых нет, потому что их нет в большинстве команд.


 


Чарльз Симоный (Charles Simonyi), выдающийся программист, со-изобретатель принципа редактирования текстов WYSIWYG,  встретился с Мартой Стюарт (Martha Stewart), сделавшей миллиарды долларов на акциях Microsoft, и побывавшей в космосе, впервые пытался решить проблему организации команды по разработке действительно большого программного продукта (синдром «Мифического человеко-месяца») созданием супер-пупер-сверхпрограммиста, который бы писал функции верхнего уровня, делегировав написание реализации функций нижнего уровня команде рядовых программистов-новичков по мере необходимости. Они назвали эту должность Program Manager (PM). Симоный гениален, но эта его идея – не очень. Вряд ли кто хотел бы быть рядовым программистом-новичком, по-моему.


 


(Примечание: Более подробно об этом можно прочитать в книге Вильями Паундстоуна «Как сдивинуть гору Фудзи?»)


 


Что должен делать PM?


 


Джейб Блюменталь, программист команды Mac Excel в конце 1980-х, возродил этот термин (PM) для другой работы. Он заметил, что разработка ПО стала настолько сложной, что ни у кого из программистов не хватало времени, чтобы разобраться, как делать программы, которые были бы и полезны, и используемы. Команда маркетологов изрекала тенденциозный вздор о потребностях покупателей, и ни у кого не было времени, чтобы поговорить с ними или перевести их МБА-сленг в нормальный список опций программного продукта. Это была масса материала по дизайну продукта, который требовал массы работы: интервью с пользователями, прогон тестовых примеров, обзор аналогичных продуктов конкурентов,  и напряженное осмысление того, как сделать вещи проще, и у большинства программистов просто не хватало на это времени (или они просто не были сильны в этом). Блюменталь воспользовался наименованим должности «Program Manager», но изменил эту должность полностью. Что же должен делать PM?


 


С тех пор, PM обязан:


 


- Разрабатывать дизайн интерфейса пользователей;


- Писать функциональные спецификации;


- Координировать работу команды;


- Служить адвокатом заказчика и


- Носить брюки банановой республики;


 


Для маленьких продуктов вам будет достаточно одного PM, но для больших продуктов, вам вряд ли хватит одного. В таком случае каждый из PM может быть ответственным за свой набор опций. Хорошее эмпирическое правило – иметь одного PM на каждую четверку программистов. Если у вас есть сложности при распределении работы, одним из подходов, который я узнал от Майка Конта (Mike Conte), является разделение продукта в соответствии с видами деятельности пользователей (user activities).


 


Например, Твиттер мог бы быть разделен по видам деятельности пользователей так:


 - регистрация и начало работы;


- отправка сообщений и чтение ответов на них;


- настройка вашего профиля;


- поиск новостей.


 


Моим первым назначением на должность PM в Microsoft была т.н. «кастомизация» работы пользователей в Excel, т.е. разработка языка для написания скриптов и макросов. Первым делом мне нужно было выяснить,  в чем нуждаются заказчики (пользователи), что я и сделал, поговорив со столькими пользователями, сколько смог, пока я не начал испытывать скуку, т.к. я уже начал слышать похожие вещи. Я потратил кучу времени, разбираясь с командой, что было бы возможно и резонно сделать в единственном 18-месячном релизе, и я потратил немало времени на выяснение, может ли команда Visual Basic'а предоставить компилятор, редактор исходного кода, и редактор окон диалога, который бы использовался в Excel для нашего макроязыка. Мне также надо было разговаривать с Apple, разрабатывающим свой собственный макроязык под названием AppleScript, и с другими командами по разработке приложений в Microsoft, в основном Word, Access, Project и Mail, которые в основном делали то же самое, что и Excel. Большую долю моей работы заняли встречи и обсуждения. Встречи, переписка по емейлу, телефонные звонки. У меня осталось на всю жизнь множество виртуальных шрамов с тех пор, и я еще вздрагиваю от страха в своем офисе, когда звонит телефон.


 


Следующим шагом стала задача зафиксировать наше видение: что-то вроде обобщенного документа, где бы говорилось, как VB должен работать в Excel, как должны были бы выглядеть некоторые примеры макросов, и это были основные фрагменты, которые мы должны были сложить вместе, и это было бы то, что решало бы проблемы пользователей. Когда это перестало вызывать слишком большое число возражений, я начал работать над более детальной спецификацией, которая объясняла, опускаясь до мельчайших деталей, как всё это будет выглядеть для пользователя.


 


Это была функциональная спецификация, но не техническая, которая описывала, как это все будет выглядеть для пользователя, а не то, как это будет сделано. (Прочитайте все о функциональной спецификации здесь –


http://www.joelonsoftware.com/artic…0000000036.html)


 


 


Честно говоря, тогда я не знал почти ничего. Только что выпущенный из колледжа, я не обладал достаточным опытом для разработки кода, тестирования, написания документации, маркетинга продукта, или создания тестовых примеров. К счастью, у Microsoft были серьезные продвинутые гуру по каждой из этих позиций, которые научили меня всему, что я знаю сегодня, и которые выполнили настоящую работу по производству выдающихся программных продуктов.


 


Например, я знал, что пользователи хотели бы копировать значение табличной ячейки в переменную:


 


x = [A1]


 


и это должно работать. Проблема была в том, что ячейка могла содержать число или строку, но Basic, был языком с ранним связыванием… Вам необходимо объявить переменнуе как целую, или с плавающей точкой, или как строковую, прежде чем вы сможете использовать её.


 


Поэтому Basic нуждался в нескольких динамических типах, но я не был достаточно крут, чтобы разобраться, как это сделать. Том Корбет (Tom Corbett), программист из команды Visual Basic, разобрался с этим. И так появились Variants и IDispatch, и Бейсик тем динамическим языком, тем, чем ваши дети сейчас называют «утилитарным программированием» (duck typing). Точнее говоря, моя работа состояла не в решении проблемы, а в том, чтобы разобраться с тем, в чем нуждаются пользователи и быть уверенным в том, что программисты разберутся с тем, как это сделать.


 


Как только спецификация была завершена, и команда разработчиков приступила к работе, у нас появилось две области ответственности: решение всех возникающих вопросов о дизайне, и обсуждение со всеми остальными командами того, что разработчики не обязаны делать. Я встречался с тестерами, объясняя им то, что им нужно делать и помогая им планировать тестирование всего и вся. Я встречался с командой документирования, чтобы быть уверенным, что они понимают, как надо написать хорошее руководство и справочник по Visual Basic. Я встречался с экспертами по локализации, чтобы разобраться с их стратегией. Я сидел с маркетологами, чтобы объяснить им выгоды VBA. Я работал с экспертами по юзабилити, чтобы помочь создать им тесты.


 


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


 


Конфликт


 


В отсутствие PM, ваш типичный супер-умный программист стремится соригинальничать, разработав экзотический и непонятный интерфейс пользователя, который заставить вас почувствовать себя VULCAN’ом (см. рисунок ниже). Типичный крутой программист печально известен как обладатель блестящего ума, который не может придумать альтернативу запоминанию 16 однобуквенных аргументов командной строки. Такие программисты стремятся цепляться за свои первоначальные идеи, особенно, если они уже успели написать для них код.


 



 


 


Одной из лучших вещей, которую PM может добавить к разработке дизайна программного продукта, это альтернативное мнение о том, как он должен быть спроектирован, надеясь на то, что оно будет более эмпатическим к таким ТОРМОЗНУТЫМ ПОЛЬЗОВАТЕЛЯМ, которых их нудное умственное бессилие требует, чтобы приложение могло быть использовано без чтения руководства пользователя, написания пользовательских emacs-lisp функций или перевода в уме чисел в шестнадцатиричную систему.


 


PM может привнести в разработку дизайна программного продукта ценные идеи, которые сделают его дружественным к обычным пользователям, чьи умственный способности не рассчитаны на чтение мануала, написание макросов, emacs-lisp функций или преобразования в уме десятичных чисел в шестнадцатиричные.


 


Хороший PM придет со своими собственными предложениями о принципах работы пользовательского интерфейса, которые могут быть лучше, или хуже, чем идеи разработчика. И грядут долгие споры. Как правило, менеджер ПО настаивает на чем-то более простом и легким для понимания пользователя, использующего телепатический пользовательский интерфейс и 30-дюймовый экран, который, однако, помещается в вашем кармане, в то время как разработчик настаивает на том, что наиболее легко реализуется в коде, с интерфейсом командной строки («что такого неудобного в этом?») и Python-связывания.


 


Одной из наиболее монументальных дискуссий, запомнившихся мне по проекту Excel 5, состоялась между разработчиками, желающими, чтобы pivot (перекрестные) таблицы перемещались по рисованному уровню над таблицей, и PM, который настаивал, чтобы pivot-таблицы находились прямо в ячейке таблицы. Этот спор продолжался довольно долго, пока PM не одержал верх, но окончательный дизайн все-таки стал намного-намного лучше, чем те варианты, которые предлагались в самом начале.  


 


Для гарантии того, что дебаты пройдут в уважительной атмосфере, и  будут обосновываться рациональной оценкой фактов, абсолютно необходимо, чтобы PM и разработчики имели равные права. Если разработчики подчиняются PM, то в ходе дебатов рано или поздно ему все это надоест, и PM просто скажет: «ОК, хватит болтать, будем делать по-моему». Если же они будут равны, этого никогда не случится. Это немного похоже на судебный процесс: мы ведь не позволяем адвокату одной из сторон быть судьей, и работаем исходя из того, что истина, скорее всего, будет выявлена в ходе дискуссии на равных. Дебаты могут быть честными, только если ни одна из сторон не имеет привилегий.


 


Это очень важный момент, так что, если вы сейчас мечтали о Салли из 11 класса, гадая, где же она сейчас,  очнитесь. Она физиотерапевт в Скоттдейле, и республиканка. А сейчас внимание. Программисты не должны подчиняться PM, что означает, кроме всего прочего, что лидером команды, или CTO, или CEO, не может быть человек, разрабатывающий спецификации.


 


Ошибкой номер один, которую делают большинство компаний – это назначить менеджера программистов, который пишет спецификации и разрабатывает дизайн продукта. Это ошибка, потому что дизайн в этом случае не рождается в честном соревновании мнений, конфликта или дебатов, так что он не может стать таким хорошим, каким мог бы.


 


Я наступил на эти грабли. В компании Fog Creek Software, я сам исполнял множество обязанностей PM, и это был вечный бой – напоминать людям, что это они должны не соглашаться со мной, если я говорю неправильные вещи. Мы не были большой компанией, но, мы в конце концов стали достаточно крупными, чтобы наконец получить настоящих PM, Дэна и Джейсона, и программисты любят спорить с ними.


 


Конечно, когда программисты уравнены в правах с PM, программисты стремятся одержать верх. И здесь я приведу то, что случалось уже не раз: программист просил меня вмешаться в спор, который он вел с PM:


 


 «Кто будет писать код?» спросил я.


«Ну, я…»


«ОК, кто делает контроль версий?»


«Я, наверно…»


«Так, в чем проблема, конкретно? У вас абсолютный контроль над содержанием каждого бита финального продукта. Что еще вам нужно? Корону?»


 


Видите ли, оказывается, что такая система возлагает на PM задачу по убеждению программиста, потому что, с одной стороны, PM несет риск, что программист сдастся, и просто станет делать то, что ему нравится. Так что, быть эффективным PM означает, что вы обязаны: а) быть правым б) заслужить уважение программистов, чтобы они признавали вашу правоту.


 


Как же заслужить это уважение?


 


Этому способствует, если, будучи PM,  вы достаточно хорошо умеете писать программы. Но это нечестно! Ведь не предполагается, что PM будет программировать. Но программисты стремятся уважать программистов больше, чем непрограммистов, не важно, насколько последние умны. Можно быть эффективным PM, не будучи программистом, но заслужить уважения программистов будет гораздо тяжелее.


 


 


Примечание: flip the bozo bit . Определить, кто является клоуном, и прекратить его слушать. (Отправить в игнор).


 


Другим способом заработать уважение команды программистов является ум, открытость идеям, и честность в любых дебатах, которые возникают. Если PM изрекает глупости, то программист может «отправить его в игнор» (установить бозо-флаг). Если PM лично или эмоционально застревает на одной точке зрения, которая становится необоснованной, то это ведет к потере изрядной доли уважения… обе стороны, но особенно PM должен эмоционально отстраняться от дебатов и стремиться рассматривать каждое новое доказательство и изменять свое мнение, когда факты требуют этого. Окончательно, если программисты видят, как PM интригует, ведя секретные переговоры с боссом или пытается разделять-и-властвовать, чтобы выиграть спор, вместо того, чтобы спорить по-честному, они утрачивают к нему доверие.


 


А когда PM теряет доверие команды программистов, все кончено. Это уже не будет эффективным. Программисты отключаются и делают все по-своему. Это приводит к ухудшению кода и потере времени, т.к. вы не только платите неэффективному PM зарплату, но и неэффективный менеджер собирает совещания и съедает время всех остальных, хотя это не делает код нисколько лучшим.


 


Спецификации? Серьезно? Это так негибко.


 


Существует множество организаций по разработке ПО, где спецификации являются символами бездумной бюрократической работы, так что все сейчас обсуждают идею о том, что не спецификации не нужны. Эти люди не имеют цели. Написание функциональных спецификаций является самым сердцем гибкой разработки, потому что это позволяет вам быстро проходить через множество вариантов дизайна до того, как вы напишете код. По сравнению с кодом, написанную спецификацию легко изменить. Сам процесс написания спецификаций заставляет вас обдумывать дизайн, который находится у вас в голове, и помогает вам быстро увидеть изменения в нем, так что вы можете повторять процесс снова и пробовать все новые варианты дизайна. Команды, которые используют функциональные спецификации, получают лучше спроектированные продукты, потому что у них есть возможность быстро исследовать большее число возможных решений. Они также быстрее пишут код, потому что, когда они начинают,  у них есть ясная картина того, что должно быть сделано. Функциональные спецификации являются настолько важными, что одним из нескольких твердых и простых правил в Fog Creek является: «Никакого кода без спецификаций» («Нет спецификаций – нет кода»).


 



 


Точная форма функциональной спецификации может иметь различное воплощение. Каждая функциональная спецификация должна объяснять, как будет вести себя программа. Она ничего не говорит о том, как код будет работать внутри. Вы начинаете с верхнего уровня: утверждение о видении, не более одной страницы на объяснение сути новой опции. Один раз ухватив смысл, вы можете разработать диаграммы … макетов экранов, показывающих продвижение пользователя по приложению, с подробными заметками, разъясняющими, как это работает. Для многих типов функциональности, особенно для нагруженного пользовательского интерфейса, как только вы получите эти диаграммы, вы выполнили задачу. Это ваша спецификация. (Джейсон Фрид, вы можете идти)


 


Чтобы научиться писать хорошие функциональные спецификации, читайте мои серии из четырех частей. Если вы хотите увидеть типовую спецификацию, написанную мной, вы можете скачать полную спецификацию проекта Fog Creek Copilot.


 


Для более сложной функциональности, со скрытым поведением, которое не может быть выражено в диаграммах пользовательского интерфейса, вам надо написать больше письменных пояснений. В любом случае, сам акт записывания спецификаций поможет вам обнаружить проблемы, конфликты, и дизайнерские нестыковки задолго до того, как вы напишете первую строку кода, так что, когда вы начнете писать код, у вас будет возникать намного меньше неожиданных проблем, которые могли бы заставить переписать код, или что еще хуже, получить псевдооптимальный дизайн.


 


Как обучиться на PM?


 


В большинстве случаев, становление PM является вопросом обучения: обучения технологии, людей, и того, как быть эффективным в политической организации. Хороший PM сочетает инженерный подход к технологии проектирования с политической способностью находить консенсус и собирать людей вместе. Пока вы будете работать над этим, есть несколько книг, которые вам следует прочитать:


 


Насколько я могу судить, книга Скотта Беркуна «Делая вещи» является единственной книгой, где довольно полно написано, что менеджер ПО должен делать, так что начните с неё. Скотт много лет был менеджером ПО команды Internet Explorer.


 


Другая большая часть обязанностей менеджера ПО – дизайн пользовательского интерфейса. Читайте Стива Круга «Не заставляйте меня думать», затем мою собственную книгу «Дизайн пользовательского интерфейса для программистов».


 


Наконец, я знаю, что это звучит банально, но книга 1937 года Дейла Карнеги «Как завоевывать друзей и оказывать влияние на людей» является фантастическим введением для развития навыков общения. Это первая книга, которую я заставляю читать всех стажеров в Fog Creek, до всех прочих, и они всегда хихикают, когда я говорю им, что ее надо прочитать, но любят ее, после того как ее прочитают.


 


Далее идут объявления о летних стажировках для студентов колледжей в фирме автора и т.п.. 


 


 

Тайный язык Microsoft (Secret language)

 


http://www.joelonsoftware.com/items/2009/12/30.html


 Secret language


 Тайный язык


 Джоэль Спольски, Среда, 30 декабря 2009


 Microsoft Careers: «Если вы ищете для себя новую роль, где вы бы могли сфокусироваться на одной из самых больших проблем, которая находится в числе первоочередных для КТ и Стива Б в  «Соревновании», построить полное понимание филиала слева направо, получить большое количество исполнительных ошибок, построить и управлять деятельностью v-команды победителей соревнования 13 районов по Линуксу и Опен Офису, и развить широкий набор маркетинговых навыков и подчиняться руководству командой, нацеленному на развитие и распознавание для высоких WHI – это вакансия для вас!»


 Ирония в том, что используется значения слов из шоу Аланса Морисетта. (видео)


 Главная причина того, что MS нуждается в команде-победителе 13, хм, «V DASHES» для соревнования с Опен Офисом, состоит в том, что они стали настолько замкнуты, что их объявления о найме полны непонятного жаргона и сокращений, которые не может понять тот, кто находится вне компании. С 93 тысячами служащих, никто даже не говорит с теми, кто находится вне компании, так что неудивительно, что они стали неестественным набором “КТ», «Стив Б», «v-команда», «высокий WHI», CSI, GM, BG, BMO (кишечная проходимость?) и проч.


 Когда я работал в MS, почти двадцать лет назад, и смеялись над ИБМ, которая изобретала альтернативные названия для всего. Всех говорили «Жесткий диск», ИБМ – «Фиксированный диск», все – «ПК», ИБМ – «Рабочая станция». ИБМ должна была содержать целый отдел людей, только для того, чтобы просто проверять страницы в руководстве, где говорилось «Эта страница предположительно будет пустой».


 Сейчас, когда вы говорите с любым, кто работал в MS более чем одну неделю, вы не можете понять слов, которыми они изъясняются. Это ничего, что вы никогда не поймете киберфанатов. Но  в MS вы никогда не поймете маркетологов, и что еще хуже, они никогда не узнают, что они говорят на своем особом языке, понятным только для них.


 Далее идет приглашение студентов колледжа на летнюю стажировку в компании автора, Fog Creeek.


 

1|2|3|4