А вот ещё про отпуск
Автор: Джоэл Сполски
Переводчик: Семён Хавкин
Редактор: Евгений Дамаскин
18 марта 2000
В 1995 году я ушёл в долгий отпуск, и сейчас тоже. Что может быть лучше отпуска?
В 1991 году я закончил институт и отправился на арендованном грузовичке в первое своё путешествие через всю страну в город Редмонд, штат Вашингтон. Первая моя работа была в Майкрософте. Тогда, должен отметить, ещё не наступила эпоха всеобщей ненависти к Майкрософту. В то время его ненавидели только студенты и юниксоманы — за то, что он делал "поделки" и скучные офисные программы для всяких клерков. Одному из моих одногруппников предложили работать над OS/2. Он отказался — "С этим кораблём я на дно не пойду!" — и пошёл учиться на юриста.
Мягко говоря, я был не рад концу учёбы. Мне хорошо жилось в атмосфере студенческой жизни, а перспектива прозябания в скучной квартире, в сером городе, где я никого не знал, меня пугала. Конечно, в Майкрософте всё так и происходит; большинство новых работников там — недавние выпускники со всех концов страны, которые оказываются в запруженных пригородах Редмонда без друзей и какой-либо личной жизни. Для типичного ботана это означает: вся жизнь в работе. Обычный день устроен так: встал, пошёл на работу (смотри не наступи на слизняков), там до позднего вечера, затем домой, телевизор, и баиньки; повторил...
Ну, у меня это было немного иначе, всё же я не совсем безнадёжный ботан; вечерами я вместо телевизора ходил в спортзал, а по выходным ездил на велосипеде вокруг озера Вашингтон и в университетский район, где проводил время в книжных магазинах, библиотеках и кофейнях и скучал по ушедшей студенческой жизни. А через пару лет я заметил, что у меня никак не складывается личная жизнь; не появилось друга; весь круг общения был из Майкрософта. Скучно.
В поисках перемен я отправился в Нью-Йорк, в отдел Консультационной Службы Майкрософта. Когда-нибудь я напишу книжку про этот жуткий сабантуй некомпетентности. Скажу только, что пробыл я там недолго. Быстрый подсчёт моих ценных бумаг показал, что за два с половиной года я накопил 120 тысяч долларов и, по моим оценкам, мог рискнуть поработать в стартапе.
Получив предложение на работу от Pipeline, одного из первых ISP в Нью-Йорке, я покинул Microsoft. Но разговоры с основателем и владельцем фирмы не привели меня в восторг, и так начался мой первый долгий отпуск.
В течение последующих девяти, что ли, месяцев я делал вот что. Во-первых, учился. Ведь это был 1994 год, Интернет вовсю набирал силу, и мне нужно было многое подзубрить, особенно после долгого плавания в закрытых водах Майкрософта ”До Меморандума”, когда ещё было принято считать, что MSN будет соревноваться с Интернетом и полностью поглотит его.
Кроме того, я поупражнялся в обдумывании своего собственного стартапа, и даже два раза. Оба упражнения закончились ничем, потому что я не нашёл подходящего партнёра и вообще толком не понимал, что делал; но хочу поздравить себя с тем, что первый стартап мог бы стать как Yahoo! а второй как Vermeer (это компания, которая превратилась в Microsoft Front Page). Где-то на моём диске лежат технические спецификации на такие продукты, что, если бы мы их сделали, то могли бы стать по-настоящему крупными компаниями. Но важна не идея, а её исполнение. К этому я в своих записках вернусь ещё не раз.
В голове у меня, кроме того, сидела идея велосипедной поездки через всю страну. Когда я понял, что со стартапами не получилось, я начал планировать путешествие на весну, как только станет достаточно тепло. (Тогда я ещё не знал, какими бывают весеннние дожди.) Поездка получилась прекрасная, можете почитать о ней в моём дневнике (тех ещё времён, 1995 год!)
Где-то в Айдахо, посреди пустой дороги, настроение у меня изменилось: я понял, что отдохнул и снова готов работать. Сидя в библиотеке в университете Boise State, я с энтузиазмом проглотил все компьютерные журналы, и мне стало радостно, что многое изменилось, и как много всего нового можно выучить. Вернувшись домой, я обнаружил, что рост акций Майкрософта чудесным образом возместил мне семь тысяч, которые я потратил на 10-недельную поездку. Сидение без работы 8 или 9 месяцев почти не отразилось на моих сбережениях.
Вот таким был мой первый долгий отпуск. Через два дня я нашёл интересную работу, и затем работал аж четыре года: сперва в Viacom, затем в Juno.
В прошлом ноябре, наши начальнички в Juno наконец-то меня достали. Работа больше не приносила никакой радости. Всё труднее и труднее было не обращать внимание на изощрённые и не столь изощрённые способы, которыми начальники всех уровней мешали работать. Что хуже, постоянная политическая их борьба и спесивость убедили меня, что шансов повлиять на ситуацию не было. Вместе с другими талантливыми, но разочарованными работниками я ушёл из фирмы.
Мне очень нравится такой подход: четыре года работать, затем год отдыхать. На сей раз я знаю точно: когда вернусь на работу, буду работать на себя, в настоящем стартапе, как его основатель. За это время я много узнал, и постепенно пришёл к мысли, что нынче в основании своей компании очень мало риска. [См. дату написания, а также дополнение. — Прим.пер.] Миллиарды не особо разборчивых венчурных баксов ищут себе хозяина; даже стартапы платят хорошую зарплату (деваться-то им некуда); а шанс добиться акта ликвидности (ну, IPO либо продажи компании) столь велик, что за время обычного рабочего стажа — скажем, работая в 4 стартапах за 10 лет — у вас появляется фантастический шанс заработать хренову тучу капусты.
Послесловие переводчика
Времена изменились и мы вместе с ними. Джоэль любезно дополнил этот текст нынешними мыслями.
Английский текст следует за русским переводом.
Дополнение автора
Джоэль Сполски, октябрь 2002.
Я написал эту статью в марте 2000 года, ещё до основания компании Fog Creek Software. С тех пор количество не особо разборчивых венчурных денег сильно сократилось. Парадоксальным образом, это делает хороший деловой план организации компании как никогда важным, так что теперь это ещё менее рискованно, чем в марте 2000 года (а ведь на сегодняшний день почти все новые компании, основанные в ту эпоху, прекратили своё существование).
I originally wrote this article in March, 2000, before starting Fog Creek Software. Since then, the number of not-very-smart venture capital dollars has been reduced a lot. Paradoxically, that makes it more important than ever to have a good business plan when you start a company, which makes it even less risky than it was in March, 2000 (by now almost every new company founded in that era has failed.)
Примечания переводчика.
Все знают теперь, что такое стартап (startup). Это небольшая компания, созданная ради исполнения какой-то деловой идеи, с расчётом на вырост. Работа в стартапах характеризуется огромным расходом сил и не столь значительной непосредственной материальной отдачей, но зато большой надеждой на будущий успех.
Реформа Майкрософта относится к записке "Internet Tidal Wave", май 1995 года, см. http://www.usdoj.gov/atr/cases/exhibits/20.pdf [444K pdf].
MSN был и остаётся майкрософтовским порталом в Интернете.
Ликвидность — способность активов превращаться в деньги быстро и легко, сохраняя фиксированной свою номинальную стоимость.
IPO , т.е. Initial Public Offering, начало циркуляции акций компании на бирже. Обычно сопровождается скачком стоимости этих акций по отношению к внутренней цене, что означает большую выгоду, хотя и на бумаге, для владельцев акций. Хорошим тоном считается привлечение работников фирмы к участию в IPO, что является для них дополнительным (а подчас и основным) стимулом заинтересованности в успехе фирмы.
В английском оригинале статья называется
More on Sabbaticals
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Безболезненные функциональные спецификации
Автор: Джоэл Сполски
Переводчик:
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Биг Маки против "обнаженного шеф-повара"
Автор: Джоэл Сполски
Переводчик: Сергей Калмаков
Редактор: Дмитрий Майоров
18 января 2001
Загадка: почему так происходит, что некоторые из крупнейших консалтинговых компаний в мире по информационным технологиям делают самую плохую работу?
Почему так случается, что "крутые" новые консалтинговые компании начинают с череды впечатляющих успехов, метеорного взлета, и быстро деградируют до посредственных?
Я размышлял об этом, и думал о том, как (моя компания) должна расти. И лучшие уроки, которые я смог найти, пришли из Макдоналдс. Да-да, я имею в виду эту ужасную сеть ресторанов-закусочных.
Секрет в том, что они не очень хороши, но каждый из них не очень хорош в точности одинаково. Если вы согласны жить с этим "не очень хорошим", то вы можете получить "биг мак" абсолютно безо всякого шанса хоть малейшего сюрприза.
Другой секрет "биг маков" состоит в том, что вы можете иметь IQ (интеллектуальный коэффициент), который колеблется между "идиот"и "баран" (используя технические термины) и все равно вы будете способны выпустить "биг мак", который будет таким же заурядным, как и все другие "биг маки"в мире. Все это потому, что настоящий секретный соус Макдональдса — это его громадное руководство, описывающее в потрясающей детализации точную процедуру, которой каждый владелец франчайза должен следовать при создании "биг мака". Если "биг мак" гамбургер жарится 37 секунд в Анкоридже, Аляска, он будет жариться 37 секунд в Сингапуре - не 36 и не 38. Что бы сделать "биг мак" вы просто должны следовать этим чертовым правилам.
Эти правила были тщательно составлены весьма разумными людьми (там в Макдональдса) так, чтобы "чайники" могли соблюдать их так же хорошо, как и смышленные люди. На самом деле правила включают все виды предосторожностей, как например звонки, которые звенят, если вы держите картошку в горячем масле слишком долго, которые были созданы, чтобы компенсировать более чем небольшие человеские слабости. В них есть секундомеры и точные времена на все. Есть система, которая должна гарантировать, что уборщик проверяет чистоту туалетов каждые полчаса (Подсказка: они не чистые.)
Короче, система подразумевает, что каждый наделает кучу ошибок, но гамбургеры, которые получатся в результате, будут, э-э, стабильно похожие, и вас всегда спросят, не хотите ли вы еще жареную картошку.
Просто для развлечения давайте сравним повара в Макдональдсе, который в точности следует набору правил и не знает ничего о пище, с таким гением как , британский красавец Джеми Оливер. (Если вы сейчас решите покинуть этот вебсайт и нажать на этот линк для того, чтобы увидеть видео в стиле MTV о том, как Обнаженный Шеф-повар готовит айоли с базиликом (Прим. переводчика: айоли - густой соус из толченого чеснока, яичных белков, лимонного сока и оливкового масла, который используют с рыбой и овощами), то вот вам мое благословение. Идите на здоровье). В любом случае, сравнение Макдональдс с изысканным шеф-поваром полностью абсурдно, но пожалуйста, придержите недоверие на минуту, потому что здесь есть, чему поучиться.
Итак, Обнаженный Шеф-повар не следует никакому Руководству. Он не измеряет ничего. Когда он готовит, вы видите, как пища летает повсюду, как бы между прочим. "Мы добавим еще немного розмари, это не повредит, и хорошенько встряхнем", говорит он. "Разомнем это все. Отлично. Просто посыпем это все везде." (Да, это действительно выглядит, как будто он просто посыпает все вокруг. Извините, но если я попробую посыпать все равномерно, это не сработает.) Это занимает примерно 14 секунд и он в основном сымровизировал полное изысканное блюдо из поджаренного порезанного морского окуня с приправами, запеченного с картофелем и грибами с салсой-верде (Прим. переводчика: салса-верде: острый соус зеленого цвета). Вкусно.
Хорошо, я думаю, очевидно, что пища "Обнаженного Шеф-повара" лучше, чем то, что вы получите в Макдональдс. Даже если это звучит глупо, давайте спросим, почему. Это вовсе не глупый вопрос. Почему большая компания с несметными ресурсами, невероятным масштабом, доступом к самым лучшим "дизайнерам" пищи, которых можно найти за деньги, и бесконечным оборотом наличных, не может приготовить приличную еду?
Представьте, что Обнаженному Шеф-повару надоело заниматься "телешоу" и он откроет ресторан. Конечно, он блестящий шеф-повар, еда будет бесподобна, так что место будет переполнено клиентами и будет шокирующе прибыльным.
Когда у вас есть шокирующе прибыльный ресторан, вы быстро осознаете, что даже если он заполнен каждый вечер, и даже если вы берете $19 за закуску и $3.95 за кока-колу, ваши прибыли скоро упрутся в естественный предел, потому что один шеф-повар может приготовить ограниченное количество блюд. Тогда вы нанимаете еще одного шеф-повара, и может быть , может быть даже в других городах.
Тут начинает проявляться проблема: то, что мы в технических областях называем проблемой масштаба. Когда вы пытаетесь скопировать свой ресторан, вы должны выбрать между тем, чтобы нанять другого классного шеф-повара вашего калибра (в этом случае этот шеф-повар, вероятно, захочет получить большую часть экстра-прибыли, которую он приносит, так что стоит ли это затевать), ил, другой вариант, вы найметеи нанять более дешевого, молодого шеф-повара, который не так хорош, но довольно скоро ваши посетители раскусят это и больше не придут в этот "клонированный" ресторан.
Обычный способ справиться с проблемой масштаба - это нанять дешевых поваров, которые ничего сами толком не знают, и дать им такие точные правила о том, как приготовить каждое блюдо, чтобы они просто "не смогли" его испортить. Просто следуйте этим правилам, и вы сделаете прекрасные изысканные блюда!
Проблема: это не работает, как задумано. Существует миллион вещей, который хороший шеф-повар делает, и которые связаны с импровизацией. Хороший повар видит потрясающие манго на фермерском рынке и импровизирует соус из манго и силантро для рыбы в этот день. Хороший повар обходит временную нехватку картофеля, создав чипсы из плодов таро (Прим. переводчика: таро - вид тропического растения). Повар-автомат, который просто следует инструкциям, может быть способен приготовить заданное блюдо, когда все работает идеально, но без настоящего таланта и мастерства он не сможет импровизировать, и именно поэтому вы никогда не увидите хикама (Прим. переводчика: хикама - толстый корень коричневого цвета, внутри белый, используемый в пищу в Латинской Америке. Сладкий и напоминающий по вкусу орех. Особенно хорош для салатов) в Макдональдсе.
Макдональдс требует особенный сорт картофеля, который они выращивают по всему свету, и который они предварительно нарезают и замораживают в огромных количествах, чтобы уберечься от нехватки. Нарезка и замораживание означают, что жаренная картошка не так хороша, как могла бы быть, зато стабильна и не требует никакого кулинарного умения. На самом деле, Макдональдс делает сотни вещей для того, чтобы быть уверенными, что продукт может быть приготовлен с постоянным качеством любым бараном, который окажется на кухне, даже если это качество "чуть-чуть" ниже.
Подводим итог вышесказанному:
Некоторые вещи нуждаются в таланте для того, чтобы их делать по настоящему хорошо. Талант трудно размножить. Один из способов, с помощью которых люди пытаются масштабировать талант, это создание талантом правил для бесталанных. Качество полученного продукта очень низкое.
Вы можете встретить точно такую же историю в ИТ консалтинге. Сколько раз вы слышали про нечто подобное?
Майк был несчастлив. Он нанял громадную компанию консультантов по ИТ для того, чтобы построить Систему. Консультанты по ИТ, которых он нанял, были некомпетентны, все время талдычили о какой-то "Методике", потратили миллионы долларов и не смогли произвести ничего.
К счастью, Майк нашел молодого программиста, который был по-настоящему умен и талантлив. Молодой программист построил всю систему в один день за $20 и пиццу. Майк был в восторге. Он рекомендовал юного программиста всем своим друзьям.
Юный Программист начал делать деньги. Скоро у него было больше работы, чем он мог справиться, и он нанял группу людей для помощи. Хорошие "специалисты" хотели слишком много оплаты акциями, так что он решил нанять еще более молодых программистов прямо из колледжа и "обучить их" в течение шестинедельного курса.
Неприятность была в том, что "обучение" не давало устойчивых результатов, так что Юный Программист начал создавать правила и процедуры для того, чтобы достичь устойчивых результатов. С годами книга правил становилась все толще и толще. Скоро она превратилась в руководство в шести томах под названием Методика.
Через несколько десятков лет Юный Программист превращается в Громадную Некомпетентную Компанию Консультантов по ИТ с Методикой с большой буквы и многими людьми, которые слепо следуют этой Методике, даже когда она не работает, потому что у них нет абсолютно никакой идеи о том, что еще делать, и они вовсе не талантливые программисты -- они просто средние выпускники различных университетов, которые прослушали шестинедельный курс.
И Новейшая Некомпетентная Компания Консультантов начинает все портить. Заказчики недовольны. И другой начинающий талантливый программист приходит и перехватывает весь их бизнес, и весь цикл начинается сначала.
Я не буду называть имен, этот цикл повторился десятки раз. Все компании по сервису в информационных технологиях становятся жадными и стараются расти быстрее, чем они могут найти талантливых людей, и они наращивают слой за слоем правила и процедуры, которые помогают делать "стабильную", но не блестящую работу.
Но эти правила и процедуры работают только тогда, когда все идет хорошо. Различные консалтинговые компании по "Веб-сайтам с поддержкой баз данных" расплодились в последние пару лет и заполнили свои ряды, обучив различных любителей четырнадцати вещам, которые нужно знать для создания веб-сайтов с поддержкой баз данных ("вот это оператор выбора select, парень, теперь построй Веб-сайт"). Но теперь, когда "доткомы" лопаются и внезапно появился спрос на программированние ГУИ (GUI) высокого уровня, умение работать с C++, и настоящую компьютерную науку, парни, которые имеют только оператор выбора в своем арсенале, должны подняться на слишком крутую лестницу знаний и не могут это сделать. Но они продолжают пробовать, следуя правилам из главы 17 о нормализации баз данных, которые таинственным образом больше неприменимы для Нового Мира. Блестящие основатели этих компаний, конечно, могли бы приспособиться к новому миру: они - талантливые компьютерные ученые, которые могут выучить все, но компании, которые они построили, не могут приспособиться, потому что они заменили талант книгой правил, и эти книги не подходят к новым временам.
В чем мораль этой истории? Опасайся Методик. Они представляют собой отличный способ привести всех к жалкому, но удовлетворительному, уровню выполнения, но в то же время они раздражают более талантливых людей, которым досаждают ограничения, наложенные на них. Мне очевидно, что талантливый повар не будет счастлив, делая бургеры в Макдональдсе, именно из-за правил. Так почему же консультанты по ИТ так много восхваляют свои Методики (Никак не пойму).
Что все это означает для ? Стать громадной консалтинговой компанией никогда не было нашей целью. Мы выполняем как средство для достижения цели. Наша долгосрочная цель — стать софтверной компанией, которая всегда прибыльна, и мы достигаем нашу цель, выполняя консалтинговые работы для дополнения софтверных доходов. Мы будем продолжать это делать до тех пор, пока наш доход от софтвера не покроет наши расходы. Когда это случится, мы все еще будем заниматься консалтингом, но будем в состоянии выбирать наши работы, и будем концентрироваться на тех работах, которые поддерживают наш софтвер. Софтвер, как вы знаете, масштабируется невероятно хорошо. Когда один новый заказчик покупает , мы делаем больше денег, не тратя никаких денег.
Более важно наше стремление нанимать на работу только лучших... мы совершенно счастливы, оставаясь небольшой компанией (хотя с шестью неделями отпуска в год найти людей несложно). И мы отказываемся рaсти до тех пор, пока люди, которых мы наняли, не выучатся достаточно для того, чтобы стать учителями и наставниками новичков.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Бионический офис
Автор: Джоэл Сполски
Переводчик: Денис Балуев
24. 09. 2003
Ну что ж.
Это заняло гораздо больше времени, чем ожидалось.
Большинство менеджеров программного обеспечения знают, как должен выглядеть хороший офис. Они также знают, что их у него нет и не будет. Похоже, что офисное пространство – штука, которую никто не может понять и ничего не может с этим поделать. Компания арендует офис сроком на десять лет, но когда бы не осуществлялся переезд, последним человеком, которого спрашивают о лучшем обустройстве офисного пространства, становится менеджер команды разработчиков, который выясняет, на что будет похож его хлев… то есть я хотел сказать - его офис с перегородками, аккурат в понедельник после переезда.
Черт возьми, уж в своей-то собственной компании я могу постараться что-то сделать!
Вот я и сделал.
Возможно, я просто архитектурный гений. Вероятно, по сравнению с неким усредненным разработчиком, я уделяю слишком много внимания тем вещам в реальном мире, которые меня окружают. Возможно, я принимаю все слишком всерьез. Но виной тому три серьезные причины:
Существует огромное количество свидетельств тому, что правильная организация рабочего пространства увеличивает производительность программиста. Особенно это касается личных кабинетов.
Имея в наличии обалденные, восхитительные личные кабинеты с окнами, гораздо проще нанимать на работу суперзвезд, которые обладают производительностью в десять раз больше чем просто блестящие программисты. Поскольку здесь, в Нью-Йорке, мне приходится соперничать с зарплатами в Бангалоре, мне нужны эти суперзвезды, так что когда люди приходят ко мне на собеседование, я должен видеть на полу их отвалившиеся челюсти. Это настоящая драма.
В конце концов, это мое рабочее место. Здесь я провожу значительную часть своей жизни вдали от родных и друзей. Такое место должно быть классным.
Архитекторы пользуются термином «бриф» для того же, что мы, программисты, используем понятие «системные требования». Вот какой бриф я дал Рою:
Личные кабинеты с закрывающимися дверями были обязательным требованием, которое даже не обсуждалось.
Программистам необходимо большое количество розеток, находящихся на уровне стола - они должны иметь возможность подключать все свои устройства без необходимости ползать по полу.
У нас должна быть возможность с легкостью перепрокладывать любые сигнальные кабели (телефонные, сетевые, кабельное телевидение, сигнализация) – так, чтобы нам никогда не пришлось вскрывать для этого стены.
Офис должен позволять программистам работать в парах.
Во время работы с монитором в течение всего рабочего дня, необходимо периодически давать отдых глазам, переводя взгляд на удаленные предметы – поэтому мониторы не должны быть расположены вдоль стен.
Рой проделал гигантскую работу. Вот за что люди платят архитекторам. Предсказываю – Рой станет своего рода экспертом мирового уровня по разработке офисов для программистских команд. Вот как он превратил мой бриф в трехмерное пространство:
Личные кабинеты. Мы получили не только просторные личные кабинеты с окнами, но также рабочие места для не-разработчиков, спрятанные в угловых альковах, так что каждый получил свое собственное рабочее место, находящееся вне поля зрения других работников.
Энергия. Каждое рабочее место оборудовано двадцатью, верно – двадцатью розетками. Четыре из них окрашены в оранжевый цвет и подключены непосредственно к UPS, находящихся в серверной, так что иметь бесперебойник в каждом кабинете теперь нет необходимости.
Розетки расположены на уровне чуть ниже стола в специальном коробе шесть на шесть дюймов, который пролегает вдоль всего стола. Такой короб - способ аккуратно спрятать все кабели, к тому же он имеет очень удобную крышку под цвет стола.
Провода. Мы использовали систему , расположенную под потолком. Она начинается в серверной и пролегает вдоль всего офиса, сквозь каждый кабинет. Система полностью доступна, поэтому, если вы захотите протянуть любой низковольтный кабель из точки А в точку Б, вы сможете сделать это легко и аккуратно. Мы переехали только в пятницу, а нас уже есть локальная сеть, которую мы протянули всего за полчаса – так что SnakeTray оправдал возложенные на него надежды.
В каждом кабинете есть свой 8-портовый свитч, поэтому вы сможете подключить свой ноутбук, свой рабочий компьютер, свой Macintosh, а также тот старый комп, который вы держите у себя для того, чтобы читать Joel On Software, когда основной компьютер перегружается при установке сегодняшнего обновления Windows. И у вас все еще остается 3 порта в запасе. (примечание специально для математических гениев – не нужно забрасывать меня письмами. Один порт занят линком к серверу) Я смеюсь над глупыми менеджерами по строительству, которые все еще считают, будто одного сетевого порта на кабинет будет достаточно. Для адвокатов – возможно.
Парное программирование.
При установке стандартных Г-образных столов многие разработчики садятся на углу, поэтому при временной совместной работе, парном программировании или просто необходимости показать кое-что на экране кому-либо, второму человеку приходилось или тянуться к коллеге вдоль всего стола или просто заглядывать ему через плечо.
Отдых для глаз.
Хотя мы и установили столы вдоль стен, в этих стенах есть внутренние окна, которые смотрят точно вдоль угла следующего кабинета прямо во внешнее окно. Благодаря столь замечательному расположению ущерба приватности не наносится, поскольку, хотя ваше окно и выходит в соседний кабинет, оно направлено так, что из большинства точек кабинета вы видите только маленький краешек другой комнаты и ее внешнее окно. Сухой остаток всего этого таков, что у каждого кабинета есть окна на три стороны, два из которых выходят наружу, создавая таким образом архитектурный паттерн . Вот оно, настоящее достижение: вы приходите к схеме, при которой каждый работник получает угловой офис в самом обычном здании. Еще одна причина найма классного архитектора – он стоит своих денег.
Мы оборудовали наш офис маленькой кухонькой и зоной отдыха с диванами, большой плазменной панелью и DVD-плеером. Мы также планируем разместить там бильярд и игровую приставку. Личные кабинеты означают, что вы можете слушать музыку на умеренной громкости без наушников и никто не будет обращать на это никакого внимания.
Подытожьте для меня.
Месячная плата за наш офис, когда он будет полностью занят, составит около 700$ на одного работника. Строительство уложилось в бюджет и было практически полностью оплачено арендодателем. Подозреваю, что сумма в 700$ на человека находится в верхней части списка для разработчиков по всему миру, но если это значит, что мы можем нанимать людей из 99.9 процентилей вместо 99, дело того стоит.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Cтратегические заметки III. Позвольте мне отказаться!
Автор: Джоэл Сполски
Переводчик: Борис Надион
Редактор: Алексей Быков
3 июня 2000 г.
Когда вы пытаетесь перевести людей с конкурирующего продукта на свой, вы должны осозновать все препятствия, связанные с таким переходом, и вы должны понять их намного лучше, чем вам может показаться сначала. В противном случае, люди не захотят перейти на ваш продукт, а вы останетесь "у разбитого корыта".
В я писал про разницу между двумя типами компаний: компанией типа "Бен и Джерри", которая пытается отхватить рынок у устоявшихся соперников, и компанией типа Amazon.com, которые пытаются вгрызаться в новые отрасли, где еще нет постоянной конкуренции. Когда я работал над Microsoft Excel в начале 90-х, это было как членский билет клуба компаний типа "Бен и Джерри". Электронная таблица Lotus 123, устоявшийся соперник, имела практически полную монополию на своем рынке. Конечно, были и новые пользователи, покупающие компьютеры, которые начинали сразу с Excel, но, по большому счету, если Microsoft хотел продавать электронные таблицы, то он должен был добиваться от людей перехода.
Самая важная вещь, которую нужно сделать в такой ситуации, - самому согласится с тем фактом, что такой переход необходим . Дирекция моего последнего работодателя, Juno, не была склонна допускать, что AOL уже достигла преобладающей позиции. Они говорили о "миллионах людей, еще не подключенных к Интернету", о том, что "на каждом рынке есть место для двух игроков: Time и Newsweek, Coke и Pepsi и так далее". Единственным, чего они не хотели говорить, было: "мы должны вынудить людей отказаться от AOL". И я не уверен, что они не боялись этого сделать. Возможно, они боялись "разбудить спящего медведя". Потом один из выдающихся программистов Juno (нет, не я) имел наглость насыпать "соль на рану" во время одного из собраний компании, задав один вопрос: "Почему мы не делаем бОльшего для приобретения пользователей AOL?" Они вытянули его из зала, орали на него около часа, и отказали ему в обещанном повышении. (Догадайтесь кто заполучил его талант?)
Нет ничего плохого в том, чтобы работать на рынке с устоявшейся конкуренцией. Кстати, даже если ваш продукт принципиально новый, как eBay, вы, наверняка, имеете конкурентов, например, частные распродажи! Не слишком паникуйте! Если ваш продукт где-то лучше, то у вас просто больше шансов переманить людей. Но вы должны посмотреть на это со стратегической точки зрения, думать стратегически - значит просчитывать на один ход дальше чем обычно.
Единственной стратегией перевода людей на ваш продукт является устранение преград . Представьте, что сейчас 1991 год. Lotus 123 - доминирующая электронная таблица со 100% долей рынка. Спросите себя: "Какие существуют преграды для перехода? Что удерживает пользователей от перехода на Excel?"
Вот такие рассуждения и обозначают, что устранение преград к переходу - самая важная вещь, которую вам предстоит сделать для захвата существующего рынка, потому что устранение всего одной преграды, вероятно, удвоит ваши продажи.
Устраните второй барьер, и вы опять удвоите продажи. Microsoft просмотрел список таких преград и проработал каждую из них:
Во время осуществления перехода от одной монополии к другой вы заметите, что существует волшебный "переломный момент". Однажды утром вы проснетесь и обнаружите, что ваш продукт имеет 80% рынка вместо 20%. Это, как правило, происходит очень быстро (с VisiCalc на 123 и затем на Excel, с WordStart на WordPerfect и затем на Word, с Mosaic на Netscape и затем на Internet Explorer, с dBase на Access, и так далее). Это обычно случается потому, что последняя преграда исчезает, и необходимость перехода внезапно становиться логичной для всех.
Важность работы над очевидными преградами перехода ясна, но как только вам кажется, что вы направили энергию на устранение таких преград, вы должны установить, какие не-такие-уж-очевидные преграды остались. И это тот самый момент, когда нужно применить хитрость, потому что не-такие-уж-очевидные преграды действительно существуют и удерживают людей от перехода.
Вот пример. Этим летом бОльшую часть времени я провожу в домике возле моря, но мои счета продолжают приходить в нью-йоркскую квартиру. И еще я много путешествую. Так вот, существует прекрасный web сервис, PayMyBills.com, который задуман для упрощения этого аспекта вашей жизни: все свои счета вы перенаправляете к ним, а они их сканируют и выкладывают для вас в web, чтобы вы могли их видеть (и оплачивать - прим. пер.) независимо от того, где вы находитесь.
На сегодняшний день стоимость этой услуги PayMyBills составляет около $9 в месяц, что выглядит разумно. Мне хотелось бы воспользоваться этой услугой, но в прошлом у меня были сплошные неудачи с использованием финансовых услуг через Интернет, например услугами компании Datek, которая сделала слишком много арифметических ошибок в моих счетах, я просто не могу поверить, что им дали лицензию. Поэтому я хочу попробовать услуги PayMyBills, но если они мне не понравятся, то я хочу иметь возможность оплачивать свои счета по-старинке.
Проблема в том, что если мне действительно не понравится, то прийдется звонить во все эти "проклятые" кредитные компании и опять сообщать об изменении моего адреса. Что-то слишком много работы. Таким образом, страх перед сложностями, которые меня ожидают при обратном переходе, удерживает меня от использования этой услуги. Ранее я называл это "незаметным запиранием" и это было что-то типа похвалы, но если потенциальные клиенты это выяснят - у вас прооблемы.
Эту преграду тоже необходимо преодолеть. Не так сложно перейти на использование услуги, как сложно будет от нее отказаться.
И это напоминает мне переломный момент с Excel, который наступил тогда, когда вышел Excel 4.0. И самой веской причиной стало то, что Excel 4.0 был первой версией умеющей сохранять таблицы в формате Lotus.
Да-да, вы слышали, что я сказал? Сохранять. Не читать. Это устраняло еще одну проблему, ту, что удерживала людей от перехода на Excel только потому, что все остальные сотрудники продолжали пользоваться Lotus 132. Им не был нужен продукт, который создавал нечитаемые другими программами таблицы, классический вопрос о яйце и курице (). Когда вы единственный фанат Excel в компании, где все остальные используют 123, то, даже если вы любите Excel, вы не сможете перейти на него, пока не станете частью среды 123.
Чтобы захватить весь рынок, вам необходимо ловко обходить каждое препятствие к переходу. Если вы забыли хотя бы про одну преграду, которая удерживает 50% ваших потенциальных клиентов, то, по определению, вы не сможете заполучить больше 50% рынка, и вам никогда не заменить главного игрока. Вы просто застряните в унылой позиции омлета из вопроса о яйце и курице.
Проблема в том, что большинство руководителей продумывают стратегию только на один шаг вперед, подобно шахматистам, которые отказываются подумать на ход вперед. Большинство этих руководителей говорит: "важно дать людям возможность конвертировать в наш формат, но зачем мне тратить ограниченный бюджет на разработку функций по конвертации из нашего формата?"
Это легкомысленный подход к стратегии. Он напоминает мне независимых продавцов книг, которые говорят: "зачем мне создавать удобства людям, которые собрались читать книги в моем магазине? Я хочу продавать им книги!" И вот однажды, в магазинах сети книжных магазинов Barnes and Nobles поставили диванчики и кофеварки, чем практически упросили людей читать книги в этих магазинах вместо того, чтобы продавать их. Теперь вы получили читателей, сидящих в магазинах часами напролет и залапывающих своими жирными руками все книги; но вероятность того, что они найдут что-то, что захотят купить, прямо пропорциональна времени, проведенному в магазине. Даже огромный и очень красивый магазин Barnes and Nobles в Айове загребает сотни долларов в минуту в то время, как независимые продавцы книг просто выбывают из бизнеса. Ребята, Shakespeare and Company на манхеттенском Upper West Side закрылись не потому, что у Barnes and Nobles книги были дешевле, а потому, что магазины Barnes and Nobles посещало больше посетителей .
Зрелый подход к стратегии - привлекая потенциальных клиентов не пытаться форсировать события. Если кто-то еще даже не является вашим клиентом, то пытаться "запереть" его - не очень хорошая идея. Если вы обладаете 100% рынка, то приходите ко мне - мы обсудим вопросы "запирания". А пока слишком рано пытаться "запирать" потенциальных клиентов, и если вас на этом "поймают", то вы "вылетите в трубу", "отпирая" их. Никто не желает переходить на продукт, ограничивающий свободу действий в дальнейшем.
Давайте рассмотрим более актуальный пример: провайдеры интернет - рынок с огромной конкуренцией. Провайдеры (ISP) теоретически не предлагают услугу по форвардингу ваших мэйлов на другой адрес после того, как вы прекратили пользоваться их услугами . Это мелочное решение худшего сорта, и я потрясен тем, что еще никому не пришла в голову такая идея. Если вы небольшой ISP, и вы пытаетесь заполучить клиентов, то подумайте о том, что эти клиенты беспокоятся по поводу самой большой преграды: им придется сообщать всем своим друзьям новый email адрес. Поэтому они даже не станут испытывать ваш сервис. А даже если и станут, то они все равно не будут сообщать друзьям свой новый мэйл, просто потому, что он может не заработать. А это значит, что они не станут получать много писем на этот адрес, что в свою очередь обозначает, что они не будут по-настоящему пользоваться вашими услугами и не увидят, на сколько эти услуги хороши. Промах.
Теперь представьте одного храброго провайдера, который обещает: "Испытайте нас. Если вам не понравиться и вы даже покините нас, то мы бесплатно сохраним за вами ваш адрес электронной почты. Навсегда. Скачите от провайдера к провайдеру сколько вздумается, только дайте нам знать, и мы будем всегда перенаправлять ваши письма на новые адреса".
Конечно, с экономистами случится припадок. Это почему же мы должны делать что-то, чтобы клиентам стало просто отказываться от наших услуг? Вероятно, этот вопрос возникает из-за узкого кругозора. Это же уже не ваши клиенты. Попытайтесь "запереть" их до того, как они стали вашими, и вы упустите их. Но если вы искренне пообещаете, что отказаться от обслуживания будет легко, как внезапно вы уберете последнюю преграду к переходу, люди устремятся к вам, а жизнь станет прекрасной навсегда. Пока кто-то не сделает с вами тоже самое.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Дорога на FogBugz 4.0: Часть I
Автор: Джоэл Сполски
Переводчик: Анар Мустафаев
Понедельник, 28 марта 2005
Большинство наших клиентов, к счастью, понимают, что принципом Fog Creek является создание полностью готового к использованию, незалеживающегося на полках программного обеспечения, которое вы покупаете по минимальной цене и которое готово к выполнению того, что вам нужно, а если оно не готово к тому, что вам нужно, ну тогда мы готовы выслушать ваши пожелания, но за 99$ вы не получите заказную версию, извините.
Некоторые из наших клиентов продолжают думать, что мы одна из тех больших промышленных программных компаний, к которым можно позвонить, договариваться с продавцом три месяца и в последний день финансового квартала заставить продавца обещать длинный список новых возможностей в обмен на полумиллионый контракт.
Это все замечательно, но у нас нет продавцов и мы не один из таких поставщиков. Наши клиенты счастливы нашей низкой ценовой политикой, но не все из них понимают, что из этого вытекает. Они просят нас прилететь в их штаб-квартиру, чтобы продемонстрировать программу их группе разработчиков. Они присылают нам длинные таблицы со списками свойств и просят нас отметить те свойства, которые мы поддерживаем. Они даже присылают ЗП (содрагаясь). ЗП – это запрос предложения. Это запрос большой компании специального предложения маленькой компании. Маленькая компания работает три недели как сумашедшая над 200 страничном предложением, распечатывает его и отправляет FedEx’ом с огромными затратами, в последнюю минуту, где его выкидывают в мусорную корзину, потому что большая компания уже имеет своего излюбленного поставщика, который на вертолете везет их в Атлантик-сити на пикники с блэкджеком и стриптизершами, и который получит контракт не важно на что, просто кто-то, по необъяснимой причине, решает купить что-то и может быть желая выслужиться, он настаивает на том, чтобы предложение было открыто для конкурентов и маленькая компания была выбрана в качестве жертвы, она должна написать предложение, которое не имеет шансов быть принятым, просто оно нужно, чтобы процесс выглядел немного менее коррумпированным, и если вы та маленькая компания, то я рекомендовал бы вам не ввязываться во все это и не тратить время на ЗП, только если вы точно не уверенны, что получите контракт.
КАК БЫ ТО НИ БЫЛО.
Кое-что я могу сказать и хорошего о наших клиентах:они дают нам хорошие советы о том, какие возможности мы должны добавить в FogBugz. Одна из наших в Fog Creek следующая: “Слушай своих клиентов, а не своих конкурентов.” Поэтому когда нам звонит потенциальный большой клиент, мы слушаем.
Как-то раз, на ранних стадиях планирования FogBugz 4.0, звонок был из одной большой некоммерческой организации. Учитывая, что они использовали много копий FogBugz, их руководителям отделов нужно было видеть все дела отдела в одном месте, даже если один отдел управлял несколькими проектами.
Таким образом, ОК, чтобы предоставить эту возможность данному клиенту, потребовалось немного времени. От того телефонного звонка до момента, когда мы предоставили клиенту альфа релиз с новой возможностью, прошло около двенадцати месяцев. Это быстрее обычного, потому что мы продолжаем ориентироваться на основные релизы через каждые полтора года. Я обосновал причину такого расписания в статье .
Многие другие возможности в FogBugz 4.0, который, в конце концов, мы выпустили 22 февраля, тоже были основанны на пожеланиях клиентов. Мы продолжали слышать от пользователей вопрос о том, как присоединить скриншот к ошибке. “О, это легко”, отвечали мы, “Alt+Print Screen, зыпускаете paintbrush, вставляете, запоминаете файл где-нибудь, запускаете ваш браузер, идете на домашнюю страничку FogBugz, нажимаете “New Case”, описываете этот случай, нажимаете кнопку выбора файла и находите файл, который вы только что создали.” Что может быть проще?
Может быть это могло бы быть чуточку проще?
Я обнаружил, что 30% ошибок, которые я ввожу, может быть полностью описано с помощью скриншота. Вот полный отчет об ошибке, который я ввел в понедельник:
Красный прямоугольник сделан с помощью инстумента выделения встроенного в программу, которая делает скриншоты. Я написал “wha?” – возможно это даже слишком много. Если бы я хотел жить с ошибкой без названия, я бы мог ввести этот отчет об ошибке с помощью четырех щелчков и перетаскивания (это звучит как хороше название для группы: “Четыре щелчка и перетаскивание” (“Four clicks and a Drag”). Или название для группы разработчиков Fog Creek, я подумаю об этом).
Дело в том, что, насколько я знаю, хотя я не уделял этому много внимания, ни один из наших конкурентов не имеет такой возможности.
Если один из наших конкурентов думает, что это здорово, то они могут скопировать нас, но это займет у них какое-то время, особенно если они читают мой сайт и покупают мою продукцию, которая поставляется каждые 18 месяцев.
Никакое количество наших конкурентов не заставило бы нас встроить возможность работать со скриншотами. Наши клиенты и не думали спрашивать нас об этом, но мы обратили внимание на то, что они продолжали спрашивать нас о возможности присоединения скриншотов, именно это мы и сделали.
Завтра будет Часть II, в которой я поговорю о собачьей еде. Приходите.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Достигая тех высот
Автор: Джоэл Сполски
Переводчик: Егор Егоров
Понедельник, 25 июля 2005
В марте 2000 года я запустил этот сайт, сделав : большинство людей ошибаются, полагая, что для создания успешной софтверной компании нужна уникальная идея.
Есть популярное мнение. Мол, при создании софтверной компании ваша задача состоит в поиске клевой идеи, решающей нерешенную доселе проблему, затем в реализации этой идеи и срывании куша. Мы бы назвали это мифом-о-лучшей-мышеловке. Но на самом деле задачей софтверной компании должна быть конвертация капитала в работающие программы. На входе — деньги, на выходе — софт.
Последние пять лет я проверяю эту теорию на практике. Формула компании, с Майклом Прайором (Michael Pryor) в сентябре 2000 года, состоит из четырех элементов:
Это довольно удобная формула. Особенно с учетом того, что нашей истинной целью создания Fog Creek было создание компании, в которой мы и сами хотели бы работать. Ныне я сделал заявление, что лучшие условия труда (или «создание такой софтверной компании, где программисты сами будут хотеть работать») приведут к прибыли так же естественно, как шоколад сводит челюсти, а .
Для нас с вами ответ, может быть, и очевиден, однако множеству других людей это утверждение должно быть доказано.
Несколько лет назад некая крупная компания рассматривала вопрос приобретения Fog Creek. Я знал, что этому не бывать: я слышал, как директор этой компании заявил, что он не вполне согласен с моей практикой найма самых лучших специалистов. Он привел мне библейскую метафору: мол, нужен лишь единственный Царь Давид, и вместе с ним армия солдат, минимально разумных лишь для того, чтобы точно выполнять его распоряжения.
Цена акции его компании спокойно себе упала с 20 до 5 пунктов, так что очень здорово, что мы не приняли его предложение. Правда, я не думаю, что в падении виноват лишь этот фетиш.
А на самом деле простейшая мудрость мира подражающих друг другу бизнес-журналистов и больших компаний, построенных на супердорогих консультантах по менеджменту, которые для всех думают, жуют им пищу и т.п., так вот, похоже, что простейшая мудрость их в том, что они считают самой важной вещью снижение стоимости программистов.
В некоторых рыночных отраслях низкая стоимость действительно важнее качества. «Уолмарт» (Wal*mart, крупнейшая сеть супермаркетов в США — прим. пер.) выросла в самую большую корпорацию на земле именно продажей дешевых, а не качественных продуктов. Если бы «Уолмарт» начали продавать высококачественные товары, цена пошла бы вверх и напрочь исчезло бы их конкурентное преимущество дешевизны. Скажем, если бы они попробовали продавать носки без пяток, выдерживающих такие издевательства, как, скажем, стирка в стиральной машине, им бы пришлось использовать для их производства весь спектр дорогих материалов, таких, как, скажем, хлопок. И тогда поднялась бы цена на каждый носок.
Так почему же в софтверной области нет места провайдеру дешевых услуг: компании, которая бы использовала труд самых низкооплачиваемых программистов? (Напомните мне спросить Кварка (Quark), как все-таки работает эта концепция уволь-всех-и-найми-самых-дешевых.)
А вот почему: дублирование программного обеспечения не стоит дополнительных денег. Это означает, что стоимость программистов распределяется по всем проданным копиям вашей программы. В области программного обеспечения вы можете поднять качество продукта без увеличения затрат на каждую проданную единицу.
Резюмируя: грамотная реализация скорее увеличивает стоимость программного продукта, чем затраты на его производство.
Грубо говоря, если вы экономите на программистах, вы создаете глючный софт, и вы не сэкономите даже тех денег...
То же самое касается индустрии развлечений.
Имеет смысл пригласить играть в вашем блокбастере, несмотря на то, что он затребует весьма высокий гонорар. Потому что его гонорар может быть разделен на миллион проданных билетов в кинотеатры, проданных лишь потому, что Бред Питт — ну такая лапочка.
Или же, если поставить вопрос иначе: имеет смысл пригласить играть в вашем блокбастере, несмотря на то, что она затребует весьма высокий гонорар. Потому что ее гонорар может быть разделен на миллион проданных билетов в кинотеатры, проданных лишь потому, что Анджелина — ну такая лапочка.
Однако я все еще хожу вокруг да около. Итак, что это значит — «быть лучшим программистом», и есть ли действительно такая большая разница между качеством софта, написанного разными программистами?
Давайте начнем с элементарного понятия продуктивности. Трудновато измерить продуктивность работы программиста. Практически все системы измерения, приходящие вам в голову (строки отлаженного кода, количество методов, количество аргументов командной строки), . Тяжело получить конкретные данные по большим проектам, потому что крайне редка ситуация, когда два программиста занимаются одной и той же задачей.
И студенты так интенсивно спорили о том, сколько нужно всего сделать для реализации поставленных задач, что профессор стал просить студентов отсчитывать, сколько времени они потратили на каждую задачу. Он собирал эти показания в течение нескольких лет.
Я потратил некоторое время и поигрался с этими данными. Это единственные известные мне статистические показания по работе множества студентов над одинаковыми заданиями, использующими одинаковые технологии и одно и то же время.
Эти данные, к тому же, грамотно собраны.
Первое, что я сделал с этими данными, — я высчитал среднее, минимальное и максимальное количество часов, затраченных на каждую из двенадцати задач. Вот результаты:
Ср. часов
Мин. часов
Макс. часов
Ст. откл. часов
Так о чем это я. Вот результаты лучшей четверти студентов:
Ср. часов
Мин. часов
Макс. часов
Ст. откл. часов
Невелика разница! Стандартное отклонение практически такое же для четверти лучших студентов. Более того, если вы внимательно посмотрите на эти данные, то станет ясно, что видимой зависимости между временем и оценкой нет. Вот типичный график одной из задач... Я выбрал задание COMPRESS01, реализацию алгоритма сжатия Зива-Лемпеля-Уелша, которое задали студентам в 2001 году. Выбрал его, потому что стандартное отклонение здесь очень близко к общему стандартному отклонению.
Нечего здесь искать, в этом-то и вся суть. Качество работы и время, на нее затраченное, — эти параметры попросту не кореллируют.
Я спросил об этом проф. Эйзенштата, и он обратил мое внимание еще на одну деталь. Поскольку работы следует сдавать до определенного времени (обычно это полночь), и штрафы за просроченную сдачу поистине драконовские, множество студентов сдаются до того, как заканчивают программу. Иными словами, максимальное время, затраченное на задачу, зафиксированное в этих данных, находится на этом уровне также и потому, что студентам просто недоставало времени на выполнение всей работы. Если бы у студентов было бесконечное время на разработку программ (что чуть больше походило бы на реальную жизнь), то тогда распределение было бы еще больше.
Эти данные нельзя назвать строго научными. Наверняка здесь не все достоверно. Некоторые студенты могли завышать время в надежде заработать некоторую симпатию и получить более легкие задачи в следующий раз. (Удачи! Задания CS 323 не менялись с 1980-го года, когда я там учился.) Другие студенты могли занижать затраты, потому что они теряли ощущение времени. Тем не менее, я не считаю большим допущением поверить в то, что эти данные показывают пятикратную или десятикратную разницу в продуктивности разных программистов.
Подождите, это еще не все!
А все потому, что гласит: «Подключение новых людей к запоздавшему проекту еще больше его задерживает». Единственный хороший программист, работающий над единственной задачей, не имеет накладных затрат на координацию действий или взаимодействие с коллегами. Пять программистов, работающих над той же задачей, должны согласовывать свои действия. Это занимает массу времени. Есть все-таки смысл держать команды, работающие над проектом, небольшими. На самом деле, .
И еще!
Истинная проблема работы посредственных программистов вместо парочки профессионалов в том, что сколько бы они ни работали над задачей, они никогда не создадут такого продукта, какой могут создать профессионалы.
Пять Сальери не напишут «Реквием» Моцарта. Никак. Даже если они будут работать над ним сто лет.
Пять Василиев Пупкиных, создателей всяческих несмешных мультяшных сериалов, в которых 20% шуток — про сисадминов, а остальные якобы смешны лишь за счет ужасного новорусского сленга... Так вот, пять Василиев Пупкиных могут потратить весь остаток своих жизней, но даже близко не создать что-то столь же хитовое, как Масяня.
Команда разработчиков плеера Creative Zen может потратить годы, улучшая свое жалкое подобие iPod, и все же никогда не выпустить что-то столь прекрасное и элегантное, как Apple iPod. И они не сомкнут свои челюсти на рыночном пироге Apple по той лишь причине, что феерический дизайнерский талант у них в команде отсутствует. Просто нет его там, и все.
Посредственность никогда не достигает тех высот, на которых спокойно парит профессионал. Количество оперных див, способных взять высокую ноту f6 в моцартовской «Королеве Ночи», так исчезающе мало... Но «Королеву Ночи» просто невозможно исполнить, не пропевая эту знаменитую f6.
Разве софт — это рассказ о тех высотах? «Может, в чем-то и так, — скажете вы, — но я работаю над софтом учета товарных накладных в индустрии утилизации медицинских отходов». . Наша беседа — о софтверных компаниях, о коробочном продукте, о том случае, когда успех или провал бизнеса напрямую зависит от качества кода.
Да и мы в последнее время видели массу великолепного софта, созданного действительно на тех высотах: софта, воплотить который посредственность просто не смогла бы.
В 2003 году Nullsoft выпустили новую версию плеера Winamp, сопроводив выпуск вот такими комментариями на :
Клевый новый дизайн!
Навороченные фичи!
Большинство функций таки работает!
Я о последнем... «Большинство функций таки работает!» — это забавно. И все счастливы, довольны плеером, используют его, говорят всем своим знакомым и друзьям. И они полагают, что Winamp — это хороший продукт, потому что они таки взяли и написали на своем сайте: «Большинство функций таки работает». Круто, да?
Если бы вы подключили еще людей в команду разработчиков Windows Media Player, смогли бы они достичь тех высот? Никогда в жизни.. Потому что чем больше людей работает в команде, тем больше шансов, что в ней найдутся натуральные снобы, полагающие, что это непрофессионально и по-детски — писать в веб «Большинство функций таки работает».
Не говоря уже об этом комментарии: «Winamp 3: Почти такое же новшество, как и Winamp 2!».
Вот такие вещи и заставили нас влюбиться в Winamp.
А с тех пор, как корпоративные слизняки из AOL Time Warner прибрали эту штуку к рукам, весь юмор с сайта исчез. Вы теперь просто-таки явно можете представить их себе, этих сальери, убийственно подавляющих малейшие признаки творческого подхода, который может отпугнуть какую-нибудь немолодую даму из Минессоты. Ценой уничтожения всего того, что заставило людей реально полюбить этот продукт.
Или давайте взглянем на iPod. Вы не можете сменить батарею. Когда аккумулятор умирает — все очень грустно. Покупайте новый iPod. Ну, или Apple готова заменить вам аккумулятор, если вы отошлете ваш iPod обратно на завод, и стоит это $65.95. Вот так вот.
Почему у вас нет возможности поменять аккумулятор?
iPod — это самое цельное устройство из всех, когда-либо виденных мною. Плеер гладкий и нежный. Такой же, как гладкий речной камушек. Одна только крышка аккумулятора могла бы полностью уничтожить это ощущение.
Apple приняла решение в пользу стиля. На самом деле iPod полон такими «стилевыми» решениями. И чувство стиля — это вовсе не то, чем обладают 100 программистов в Microsoft или 200 промышленных дизайнеров в ошибочно названной компании Creative (Сreative — творчество — прим. пер.) Потому что у них нет (Jonathan Ive), а Джонатан Айв на дороге не валяется.
Простите, что я все не перестаю восхвалять iPod. А это прекрасное колесико управления с щелкающим звуком! Apple вложила дополнительные деньги, встроив динамик в сам iPod для того, чтобы этот клик исходил прямо из-под самого колесика управления. Они могли бы сэкономить много монеток, денег!.. если бы они воспроизводили звук щелчка только через наушники. Но колесико управления дает вам ощущение полного контроля над плеером. Люди счастливы, когда обладают властью. Счастливы. Тот факт, что колесико управления реагирует на ваши команды мгновенно, мягко, да еще и подтверждает команды акустически, — это кайф. А остальным 6,000 продающимся моделям посредственной портативной техники нужно так много времени, чтобы включиться. В течение минуты вам надо поглядывать на этот кусок мусора, только чтобы понять, готов он уже работать или нет... Так у кого власть? У вас? Вспомните, как давно у вас был мобильный телефон, который включался сразу после нажатия кнопки?
Стиль.
Счастье.
Чувства.
Это не вопрос десятикратной разницы в продуктивности. Это о том, что «среднепродуктивный» разработчик никогда не взлетит на те высоты, на которых создается великолепный софт.
К сожалению, это не касается некоробочной разработки ПО. Внутренний программный продукт редко бывает настолько важен, чтобы для его разработки имело бы смысл нанимать звезд. Никто не приглашает Аллу Борисовну петь на свадьбах. Вот почему программисту светит более успешная карьера в софтверной компании, а не в отделе информационных технологий банка.
Рынок ПО сегодня представляет собой игру, в которой «победитель забирает все». Кроме Apple, никто не зарабатывает на MP3-плеерах. Никто не зарабатывает на электронных таблицах и текстовых процессорах, кроме Microsoft. Да, я знаю, что они предприняли определенные шаги, чтобы избавиться от конкурентов, но это ничего не меняет: рынок ПО — система, где победитель забирает все.
Вы не можете себе позволить быть продуктом «номер два» или поставлять «достаточно хорошего уровня» программу. Программа должна быть заметно хороша, где «заметно» означает, что покупатели именно видят ее качество. Выхлоп, который вы получите с команды действительно — действительно — талантливых программистов, — это единственный шанс стать заметным. Вот и вся формула:
В английском оригинале статья называется
Джоель Спольски - основатель , небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Две истории
Автор: Джоэл Сполски
Переводчик: Владимир Комаров
Редактор: Егор Рогов
19 марта 2000 г.
Сегодня я расскажу вам две истории из моей жизни, которые наглядно объясняют, почему одни компании выходят в лидеры, а другие терпят поражение за поражением. Вся разница между хорошим и плохим управлением кроется в том, насколько свободно чувствуют себя разработчики. Либо вы доверяете им, и они просто делают своё дело, либо вы устанавливаете тотальный контроль, как за официантами в McDonald’s, получая взамен вместо работы весьма изобретательные отмазки или откровенный саботаж.
Первая компания, где я работал, называлась Microsoft. Первым моим проектом был макроязык для Excel. Достаточно быстро я в общих чертах сформулировал требования к языку, назвав его Excel Basic (позже он превратился в Visual Basic for Application, но это уже совсем другая история). Неожиданно на горизонте возникла некая «Группа Разработки Архитектуры Приложений» (ГРАП). Они почему-то считали, что на самом деле это они занимаются «стратегией развития макроязыков», и всё, что так или иначе связано с макросами, их касается. Они затребовали мою спецификацию.
Я поинтересовался у коллег, что же это за загадочная группа? Оказалось, что в эту группу входят всего 4 человека, имеющих степень PhD (это само по себе необычно для Microsoft). Никто из моих коллег не воспринимал эту группу всерьёз. На всякий случай я отправил им свою спецификацию и договорился о встрече — вдруг они посоветуют что-нибудь стоящее!
Как и ожидалось, ничего интересного, одна болтовня. Оказалось, что эти учёные мужи в восторге от возможности наследования. Они считали, что люди, которые пишут макросы для Excel, будут активно пользоваться наследованием. В конце концов, один из них сказал: «Ладно, всё это очень хорошо. Но кто-нибудь из руководства одобрил вашу спецификацию?»
Я рассмеялся. Несмотря на то, что я работал в Microsoft всего несколько месяцев, я знал, что никто ничего не «одобряет». Да что там одобрение, ни у кого не было времени, чтобы просто прочитать спецификацию! Программисты ежедневно требовали от меня новой порции текста, чтобы можно было писать код. Мой начальник достаточно ясно дал понять мне (а его начальник — ему), что никто ничего не понимает в макросах, и никто, кроме меня, макросами не занимается. Следовательно, все решения, которые я принимаю, уникальны, а потому правильны. И тут какой-то тип из какой-то странной группы говорит о каком-то «одобрении»!
Достаточно быстро я выяснил, что эти академики знают о макросах гораздо меньше меня. Например, я поговорил с несколькими разработчиками макросов и с людьми, давно использующими Excel, чтобы выяснить, что именно они делают или хотели бы делать с помощью макросов. Как правило, это был пересчёт значений в таблицах по формулам или сортировка и группировка данных. Однако учёные из ГРАП, много думавшие над Серьёзной Проблемой Написания Макросов, не могли привести ни одного примера макроса. В конце концов, один из них выдал, что «если в Excel есть подчёркивание и двойное подчёркивание, то возможно, что пользователь захочет написать макрос для тройного подчёркивания». Безусловно, крайне актуальная задача. В общем, с тех пор я их попросту игнорировал, правда, очень вежливо.
Во главе ГРАП стоял некто Грег Уиттен (Greg Whitten). Это был человек №6 в Microsoft. Никто не знал, чем он занимается, но зато все знали, что он обедает с Биллом Гейтсом, и GW-BASIC назван в честь него. Получилось, что я обидел Самого. Грег собрал большое совещание, где заявил, что команда разработчиков Excel (то есть я) игнорирует принятую «концепцию макроязыков». Мы попросили его более подробно изложить свои претензии, но он не сумел привести ни одного убедительного примера. Представляете, каково это — совсем зелёному выпускнику колледжа победить в споре человека №6 в Компании? (Можете ли вы вообразить себе такую ситуацию в вашей компании? [в оригинале — Grey Flannel Suit company]) Мой начальник Бен Вальдман (Ben Waldman, сейчас вице-президент Microsoft) стоял за меня горой. В конце концов, мы же выпустили продукт, поэтому нам и судить о том, как надо делать!
На этом я считал инцидент исчерпанным. Если бы господа из ГРАП вздумали предъявить ещё какие-нибудь аргументы в пользу своей позиции, я готов был спорить с ними хоть до посинения — лишь бы не мешали работать. Но случилось нечто, выходящее за рамки моих представлений о реальности. Мы с коллегами обедали, когда ко мне подошёл Пит Хиггинс (Pete Higgins). Он был руководителем всего проекта Office, и я очень хорошо знал его, но не думал, что он знает меня.
— Как дела? — спросил он. — Я слышал, у тебя какие-то проблемы с ГРАП?
— Ничего страшного, — ответил я.
— Понял, — ответил он. А на следующий день меня ждало невероятное известие: Группа Разработки Архитектуры Приложений была распущена. Мало того, все её члены были переведены в разные отделы, подальше друг от друга. Я больше никогда не слышал ни об одном из них.
Меня, разумеется, не тронули. В Microsoft так заведено — если ты руководишь проектом разработки продукта, то ты — царь и бог во всём, что касается этого продукта. То, что ты работаешь в компании меньше полугода, не имеет никакого значения. Никто не может ставить тебе палки в колёса, даже человек №6.
У такой идеологии есть два огромных преимущества. Во-первых, разработчик начинает более ответственно относиться к своей работе. Он уже не может спрятаться за широкую спину менеджера, который «одобрил» спецификацию. Менеджеры вообще не читают спецификаций; их задача — нанять умных людей и обеспечить им условия для работы. Во-вторых, разработчику просто нравится работать в такой компании. Ну скажите, кому не хочется быть «царём и богом» хотя бы в своей маленькой области? Особенность процесса разработки программного обеспечения в том, что его достаточно легко разбить на мелкие независимые подзадачи, разделив тем самым ответственность между разработчиками. Именно это и есть главная причина, почему программисты так любят работать в Microsoft.
Через несколько лет работы в Juno я занимался разработкой новой процедуры регистрации. Мы готовили новый релиз программного обеспечения, Juno 3.x, и группа под моим руководством должна была полностью переделать эту процедуру. К тому времени я уже занимал относительно высокую должность. У меня были серьёзные достижения, и моё начальство было довольно моей работой. Но доверять мне они не могли. «Тотальный контроль и слежка» — это было у них в крови.
В процессе регистрации пользователь должен ввести свой день рождения. Это очень незначительная часть вопросника, который Juno предлагала своим клиентам. Почти 30 экранов самых разных вопросов — ваш любимый вид спорта, сколько у вас детей и сколько им лет, и так далее, около сотни вопросов. Чтобы сделать процедуру регистрации хотя бы чуточку проще, я решил сделать поле для ввода даты обычной строкой. Пользователь мог набрать «8/12/74» или «12 Aug 74» или даже «August 12, 1974». В общем, как в Outlook — как бы вы ни ввели дату, программа всё равно её распознает.
Моему начальнику это почему-то не понравилось. Сделать по-своему стало для него делом принципа. Сначала он наорал на дизайнера, делавшего эту страницу, причём мне ничего не сказал. Потом он наорал на меня. Потом он стал каждый день напоминать мне, чтобы я сделал так, как нравится ему. Мало того, он пожаловался директору, и устроил настоящее шоу из того, как директор критиковал мой новый дизайн. В Juno даже директор может вмешаться в процесс разработки на самом нижнем уровне — фактически, это чуть ли не норма.
Излишне говорить, как меня это разозлило. Это была мелочь, дело вкуса. Кому-то больше нравился мой вариант, кому-то — его. Но дело не в этом. Дело в том, что вся идеология компании может быть выражена фразой «ты будешь, будешь, чёрт возьми, делать так, как Я хочу!». Вместо дискуссии о принципе построения интерфейсов — борьба амбиций.
Я не хочу сказать, что уволился из Juno из-за этого случая, но причина, по которой я оттуда ушёл, должна быть вам понятна: сколько бы ты там ни работал, какая бы у тебя ни была репутация, какую бы должность ты ни занимал — ты на самом деле ничего не решаешь, даже на самом примитивном уровне. Можешь взять все свои идеи, наработки, опыт, ум, свернуть их в трубочку и засунуть в .... В Juno куча менеджеров, примерно четверть от общего количества сотрудников, и большую часть времени они занимаются тем, что суют свой нос всюду, куда могут дотянуться, и контролируют всё, что поддаётся контролю. Разительный контраст с Microsoft, где для того, чтобы подтвердить твои полномочия в принятии решений могут запросто выгнать вице-президента.
В какой-то мере такой ужасный менеджмент в Juno — следствие географического положения компании: она расположена не на Западном побережье, а в Нью-Йорке, куда ещё не докатились «новые веяния». Кроме того, это следствие крайней неопытности менеджеров снизу доверху, включая директора — молодого человека 29 лет от роду, никогда не работавшего нигде, кроме D. E. Shaw. Директор постоянно лез в дела, которые его совершенно не касались, например, исправлял сообщения об ошибках. Главный инженер постоянно кричал на своих подчинённых, стоило им чуть-чуть усомниться в правильности его решений. Они вымещали свою злость на программистах, а те, в свою очередь, приходили домой и давали пинка собаке. Сравните это с Microsoft, где большинство менеджеров ведут себя так, словно их важнейшая работа — убрать с дороги мебель, чтобы программист, не дай бог, не споткнулся и не сбился с мысли.
В английском оригинале статья называется Two Stories
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Двоекультурие
Автор: Джоэл Сполски
Переводчик: Михаил Kиселев
14 декабря 2001 г.
На сегодняшний день, Linux и Windows функционально более похожи, чем отличаются друг от друга. Они оба поддерживают одинаковые основные метафоры программирования, от командной строки до графического интерфейса пользователя (GUI) и веб-серверов; они организованы вокруг фактически одинаковой оболочки системных ресурсов, от похожих файловых систем, памяти до сокетов, процессов и нитей. Они не более чем набор основных сервисов обеспечиваемых каждой операционной системой для ограничения видов приложений, которые вы можете создать.
Всё что осталось, это разница культур. Да, все мы едим пищу, но кроме того, одни едят сырую рыбу с рисом используя деревянные палочки, а мы руками едим пластины говядины на хлебе. Культурная разница не означает, что Американский желудок не сможет переварить суши или что Японский желудок не переварит Биг Мак, и это не означает что не существует Американцев которые едят суши или Японцев которые едят гамбургеры, но это означает, что у Американца впервые сошедшего с самолёта в Токио появляется ошеломляющее чувство что это место странное, чёрт возьми, и неважны философствования о том, что в сущности все мы одинаковые, мы все любим и работаем и поём и умираем будет важнее тот факт, что Американцы и Японцы никогда по настоящему не смогут смириться с устройством чужого туалета.
Какова культурная разница между программистом для Windows и Linux? Существует много деталей и тонкостей, но по большей части это сводится к одной вещи: культура Unix ценит код, который полезен для других программистов, в то время как культура Windows ценит код предназначенный для не-программистов.
Это, конечно же, сильное упрощение, но на самом деле это большая разница: программирование для программистов или конечных пользователей? Всё прочее это комментарии.
Часто обсуждаемым Эриком С. Рэймоном была недавно написана большая книга названная "Искуство программирования в Unix" подробно изучающая его собственную культуру. В можете купить книгу и прочитать её на бумаге или, если политика Рэймонда слишком анти-идиотична для вас чтобы решить дать ему деньги, вы можете даже прочитать её онлайн бесплатно и быть уверенным что автор не получит ни копейки за свою трудную работу.
Взглянем на небольшой пример. Культура программирования Unix базируется на высоко уважаемых программах которые могут быть вызваны из командной строки, получая аргументы которые управляют каждым аспектом их поведения, и результат работы которых может получен в виде строго форматированного, машиночитаемого текста. Такие программы ценятся, потому что они легко могут быть включены в состав других программ или больших системы программ, программистами. Возьмём один простой пример, существует основная ценность в культуре Unix, которую Рэймонд назвал "Молчание - золото", что означает, что программа которая сделала точно то, что вы сказали ей сделать успешно, не должна выдавать . Это не имеет значения, что вы набрали 300 символов в командной строке, чтобы создать файловую систему, или скомпилировать и установить сложный кусок программы, или послать ракету ракету с космонавтами на Луну. Если это получилось, то общепринято просто ничего не выводить. Пользователь должен заключить из появления следующего приглашения в командной строке, что все должно быть в порядке.
Это важная ценность в Unix, потому что вы программируете для других программистов. Как Рэймонд подаёт это, "Программы которые бормочут не имеют склонности хорошо работать с другими программами". Напротив, в культуре Windows вы программируете для тёти Мэдж и тёта Мэдж может заключить, наблюдая что программа которая не выдаёт результата потому что она завершилась успешно, не отличается от программы которая не выдала результата потому, что она завершилась неудачно или программы которая не выдала результата потому что она неправильно истолковала ваш запрос.
Подобным образом культура Unix ценит программы которые остаются . Они не очень любят GUI, за исключением губной помады наносимой прямо поверх текстовой программы, и они не любят бинарных файловых форматов. Это потому что текстовый интерфейс проще для программирования, по сравнению с GUI интерфейсом, говорят они, который почти невозможно программировать за исключением некоторого другого программного обеспечения, вроде встроенного скриптового языка. Здесь мы опять видим что культура Unix ценит создание кода, который полезен для других программистов, что редкая цель в программировании для Windows.
Это не говорит что все Unix программы сделаны исключительно для программистов. Далеко не так. Но культура ценит вещи которые полезны для программистов, и это поясняет одну или две вещи про одну или две вещи.
Предположим вы взяли программиста Unix и Windows программиста и дали каждому задачу создать одинаковое приложение для конечного пользователя. Unix программист создаст ядро управляемое коммандной строкой или с текстовым интерфейсом и возможно, вдобавок создаст GUI который управляет этим ядром. Таким образом оснвные действия приложения будут доступны другим программистам которые могут вызвать программу из командной строки и прочитать результаты как текст. Windows программист будет стремиться начать с GUI и возможно, как дополнение, добавит скриптовый язык который может автоматизировать работу GUI интерфейса. Это уместно для культуры в которой 99,999% пользователей не программисты никаким путём, образом или формой и не имеют интереса быть ими
Существует одна значительная группа программистов для Windows которые преимущественно пишут код для других программистов: это сама команда создателей Windows в Microsoft. Способ которым они делают вещи это создание API вызываемых из языка C, которые обеспечивают функциональность, и затем создание GUI приложений которые вызывают этот API. Всё что вы можете сделать из пользовательского интерфейса Windows может также быть сделано используя программный интерфейс вызываемый из любого приемлимого языка программирования. Например, Microsoft Internet Explorer сам по себе это едва 89 кб программа которая связывает вместе множество очень мощных компонентов которые свободно доступны искушённым Windows программистам и которые созданы главным образом, чтобы быть мощными и гибкими. К сожалению, пока программисты не имеют доступа к исходному коду этих компонентов, они могут использованы лишь способами которые были точно предсказаны и позволены разработчиками компонентов Microsoft, которые не всегда удачны. И иногда там есть ошибки, обычно доставляющие проблемы лицу вызывающему API, которые трудно или невозможно отладить без исходного кода. Культурная ценность Unix делает его более простой средой для разработки. Любой разработчик для Windows раскажет вам про четыре дня потраченные на отслеживание ошибки потому что он думал что размер памяти возвращённый LocalSize будет тот же, что размер памяти первоначально запрошеный LocalAlloc, или другую подобную ошибку которую они могли исправить за 10 минут если бы они могли видеть исходный код библиотеки. Рэймонд придумал чтобы проиллюстрировать это, которая будет звучать искренно для каждого кто когда-либо использовал библиотеку в двоичном виде.
Хорошо, теперь вы получили эти весткие аргументы. Unix лучше потому что вы можете отлаживать в библиотеках. Windows лучше потому что тётя Мэг получает какое-нибудь подтверждение, что её электронное письмо действительно было послано. Фактически, одна не лучше чем другая, они просто имеют различные ценности: Unix делает вещи лучше для других программистов, это основная ценность и Windows делает вещи лучше для тёти Мэг, это основная ценность.
Давайте взглянем на другую культурную разницу. Рэймонд говорит, "Классическая документация для Unix написана кратко но полно... Стиль предполагает активного читателя, который способен сделать очевидные выводы про недосказанное выведя их из того что сказано, и кто имеет уверенность в себе чтобы доверять этим заключениям. Читайте каждое слово тщательно, потому что редко вам скажут что-либо дважды." Ой вэй, я думаю он действительно учит молодых программистов писать более невыносимые страницы помощи.
Для конечного пользователя, вы никогда не уйдёте от этого. Рэймонд может называть это "упрощающая снисходительность", но культура Windows понимает, что и если они решили прочитать вашу документацию, они прочитают лишь минимальное количество, так что вы должны пояснять вещи повторно... действительно, критерий хорошего файла помощи в Windows это то, что любую отдельную тему может прочитать средний читатель без дополнительного знания любой другой темы справки.
Как мы получили различные основные ценности? Это другая причина по которой книга Рэймонда так хороша: он идёт далеко в историю и развитие Unix и переносит молодых программистов со всей собранной историй культуры назад в 1969. Когда Unix был создан и когда было сформированы его культурные ценности, не существовало конечных пользователей. Компьютеры были дорогими, компьютерное время было дорогим, и изучение компьютерной техники означало изучение программирования. Это не удивительно, что появившаяся культура ценила вещи которые полезны для других программистов. По контрасту, Windows был создан с единственной целью: продать так много копий сколько возможно для прибыли. Туеву хучу копий. "Компьютер на каждый стол и в каждый дом" было точной целью команды которая создала Windows, постановила его повестку дня и определила его основные ценности. Лёгкость использования для не-программистов была единственным путём чтобы попасть на каждый стол и в каждый дом и так usability ?ber alles стала культурной нормой. Программисты, как аудитория, были крайним дополнением.
Культурный раскол так отчётлив что Unix никогда по настоящему не делал никаких вторжений на десктопы. Тётя Мэрдж не может по-настоящему использовать Unix, и повторяющиеся попытки сделать приятную оболочку для Unix чтобы тётя Мэрдж могла использовать проваливались, единственно потому что эти усилия делались программистами которые были погружены в культуру Unix. Например, Unix имеет ценность - , который исторически, пришёл от создателей . Это прямо ведёт к расколу в пользовательских интерфейсах; никто небыл вполне способен согласовать все детали как пользовательский интерфейс десктопа должен работать, и они думают, что это правильно, потому что их культура ценит это разнообразие, но для тёти Мардж это очень даже не хорошо использовать различные пользовательские интерфейсы для вырезания и вставки (cut and paste) из одной программы, которую она использует в другую. Хорошо, теперь мы пришли, 20 лет после того, как разработчики Unix начали пытаться изобразить хороший пользовательский интерфейс для их систем, и мы остаёмся на точке, где CEO крупнейшего продавца Linux . Я слышал экономистов требующих, что Силиконовая долина никогда не будет создана, скажем, во Франции. Потому что Французская культура даёт такое суровое наказание за ошибку, что предприниматели не готовы рискнуть этим. Может быть те же самые вещи действительны для Linux: он может никогда не стать операционной системой для десктопов потому что культурные ценности предотвращают это. OS X это доказательство: Apple наконец создала Unix для тёти Мардж, но только потому что инженеры и менеджеры в Apple были привязаны к культуре конечного пользователя (которую я по-имперски назвал "культурой Windows" даже не смотря на то, что исторически она порождена Apple). Они отвергли фундаментальное правило программистко-центричности культуры Unix. Они даже переименовали основные директории - еретики! - используя обычные английские слова вроде "applications" и "library" вместо "bin" и "lib".
Рэймонд пытался сравнить и сопоставить Unix с другими операционными системами, и это действительно самая слабая часть этой в других отношениях великолепной книги, потому что он на самом деле не знает того, о чём говорит. Когда бы он не открывал свой рот говоря о Windows он показывает, что его знание о программировании для Windows пришло преимущественно из чтения газет, не из настоящего программирования для Windows. Это нормально; он не Windows программист; мы простим это. Что типично для каждого, кто имеет глубокие знания об одной культуре, он знает каковы его культурные ценности но не вполне осведомлён о различиях между частями своей культуры которые универсальны (убийство старых леди, программы которые падают: всегда плохо) и частями культуры которые применимы только когда вы программируете для программистов (блюда из сырой рыбы, аргументы коммандной строки: зависят от аудитории).
Существует слишком много монокультурных программистов, которые, подобно типичному американскому парню, который никогда не покидал Сант Паул в Минесоте, не могут действительно обьяснить разницу между культурной ценностью и ядром человеческой ценности. Я встречал слишком много программистов Unix которые насмехались над программирование в Windows, считая что Windows дикий и тупой. Рэймонд также слишком часто попадает в ловушку недооценки ценности других культур, без учёта того, окткуда они произошли. Это гораздо реже, найти такую слепую приверженость среди программистов Windows, которые, в целом, ориентированы на решение и космополитичны. Под конец, Windows программисты признают недостатки их культуры и прагматично скажут: "Смотрите, если вы хотите продать текстовый процессор множеству людей, он запускается на их компьютерах, и если это означает что мы используем Злой Реестр вместо элегантных файлов ~/.rc чтобы хранить наши настройки, пусть будет так." Непреложный факт, что мир Unix полон самодовольных культурных преимуществ, "защиты" и slashdot-karma-whoring сектанства в то время как мир Windows более практичен ("да, что бы ни было, я просто должен сделать жить здесь") стержень из культуры которая чувствует себя под блокадой, неспособна вырваться из серверного клозета и рынка приверженцев и стать основным декстопом. Этот haughtiness-from-a-position-of-weakness наибольший изьян "Искусства программирования в Unix", но это действительно не большой изьян: в целом книга так полна невероятно интерестными проникновениями в сущность так многих аспектов программирования что я согласен держать мой нос во время редких дурнопахнущих идеологических проповедей потому что там так много для изучения о универсальных идеалах from the rest книги. Действительно, я должен рекомендовать эту книгу разработчикам любой культуры на любой платформе с любыми целями, потому что так много ценностей которые она возвещает универсальны. Когда Рэймонд что формат CSV находится ниже по отношению к /etc/passwd формату, он пытается заработать очки для Unix против Windows, но вы знаете что? Он прав. /etc/passwd легче анализировать чем CSV, и если вы читаете эту книгу, вы узнаете почему и вы станете лучшим программистом.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
I письмо о стратегии: Ben and Jerry's против Amazon
Автор: Джоэл Сполски
Переводчик: Владимир Гуров
Редактор: Тверьянович Дмитрий
12 мая 2000 года
Создаете компанию? Вам необходимо принять одно очень важное решение, поскольку оно касается всех остальных ваших действий. Не важно, какие это действия, но вы, безусловно, должны определить, какому лагерю вы принадлежите, и осуществлять все остальные действия соответствующим образом, иначе вас постигнет несчастье.
Что это за решение? Будет ли ваша компания расти медленно, органично и с прибылью, или это будет большой взрыв с очень быстрым ростом и уймой капитальных вложений.
Органичной моделью будет начать с малого, с ограниченными целями, и медленно развивать свое дело в течение длительного промежутка времени. Я буду называть это , поскольку Ben and Jerry's весьма хорошо соответствует данной модели.
Другая модель, в просторечии называемая "Быстрый Рост" (также известна как "Захват Территории"), требует от вас собрать большое количество инвестиций, и работать так быстро, как только возможно - для того, чтобы быстро вырасти, не обращая внимания на прибыльность. Я буду называть это , потому что Джефф Бизос (Jeff Bezos), основатель этой компании, фактически стал знаменитым представителем Быстрого Роста.
Давайте посмотрим на некоторые различия между этими моделями. Первое, что вам надо выяснить: есть ли у дела, которое вы собираетесь открыть, конкуренция или ее нет?
Если у вас нет настоящих конкурентов, как у Amazon, есть шанс, что вы добьетесь успеха в "захвате территорий", то есть как можно быстрее соберете столько клиентов, что последующим конкурентам придется преодолеть весьма серьезное препятствие для того, чтобы войти на тот же рынок. Но, если вы собираетесь работать в отрасли, где уже есть группа прочно установившихся конкурентов, идея "захвата территории" бессмысленна.
Вам необходимо создавать собственную клиентскую базу, переманивая клиентов ваших конкурентов.
Вообще говоря, предприниматели не в восторге от идеи выхода на рынок, наполненный этими ужасными конкурентами. Лично я не боюсь установившейся конкуренции; вероятно, потому что я работал над Microsoft Excel в тот период, когда он почти полностью взял верх над Lotus 123, который в действительности считал этот рынок своим. Текстовый процессор номер один в мире, Word, вытеснил WordPerfect, который вытеснил WordStar - все они были почти монополистами в то или иное время. И Ben and Jerry's постепенно стала легендарной компанией, хотя и непохоже, чтобы до момента их прихода на рынок вы не могли купить мороженое. Вытеснение конкурента не является невозможным делом, если это действительно то, что вы хотите сделать. (Я расскажу о том, как сделать это, в одном из следующих Писем о стратегии).
Другой вопрос, связанный с вытеснением конкурентов, касается сетевых эффектов и клиентской привязанности:
Хорошим примером этого является eBay. Если вы хотите продать ваши старые часы Patek Philippe, вы получите более выгодную цену на eBay, потому что там больше покупателей. Если вы хотите купить часы Patek Philippe, вы будете искать на eBay, потому что там больше продавцов.
Другим примером очень сильного сетевого эффекта являются такие проприетарные чат системы, как ICQ или AOL Instant Messenger. Если вы хотите початиться с людьми, вы вынуждены идти туда, где эти люди обитают, а у ICQ и AOL пока наибольшее количество пользователей. По теории вероятности, ваши друзья пользуются именно одним из этих сервисов, а не такими мелкими как MSN Instant Messenger. При всей силе, средствах и маркетинговом опыте компании Microsoft, не похоже, чтобы ей удалось потеснить конкурентов на рынке онлайновых аукционов и систем обмена мгновенными сообщениями, поскольку сетевые эффекты там очень сильны.
"Привязанность" - это когда в фирме есть что-то, что заставляет людей не желать смены партнера. Никто не хочет менять своего интернет-провайдера, даже если качество предоставляемых услуг не очень хорошее, из-за проблемы, связанной с изменением адреса электронной почты и извещением всех о новом адресе. Люди не хотят переходить на другой текстовый процессор, если их старые файлы не будут читаться в новом текстовом процессоре.
Еще лучше, чем просто привязанность, ее менее заметная разновидность, которую я называю скрытая привязанность: услуги, к которым вы оказываетесь привязанными, даже не осознавая этого. Например, все эти новые сервисы, подобные PayMyBills.com, которые получают за вас ваши счета, сканируют их и показывают вам через интернет. Они обычно предоставляют три месяца бесплатного обслуживания. Но, когда эти три месяца проходят, и вы не хотите продолжать пользоваться этими услугами, у вас не остается другого выбора, кроме как связаться с каждым из тех, кому вы должны платить по счетам, по отдельности и попросить их отсылать ваши счета снова к вам домой. Явная рутинность этих операций, вероятно, предазначена для того, чтобы не дать вам отказаться от услуг PayMyBills.com -- уж лучше просто оставить им эти несчастные $8.95 в месяц с вашего ванковского счета. Попались!
Если вы собираетесь заняться бизнесом в сфере, где имеются естественные сетевые эффекты и привязанность и нет установившихся конкурентов, вам предпочтительнее использовать модель компании Amazon, иначе кто-нибудь другой ей воспользуется и вам просто не удастся найти точку опоры для вашего бизнеса.
Маленький пример. В 1998 году, компания AOL затрачивала много денег, чтобы число клиентов росло со скоростью один миллион каждые пять недель. У AOL есть такие приятные особенности, как места для чата и обмен мгновенными сообщениями, которые обеспечивают скрытую привязанность клиентов. Как только вы нашли группу друзей, с которыми вам нравится чатиться, вы просто не будете менять интернет-провайдера.
Это все равно, что пытаться сменить всех старых друзей на новых. По моему мнению, это ключевая причина, по которой AOL может требовать с клиентов около $22 в месяц, тогда как кругом полно интернет-провайдеров с ежемесячной абонентской платой около $10.
Когда я работал в Juno, руководство просто не смогло понять этой особенности и они упустили свою лучшую возможность взять верх над AOL в период захвата территории, когда каждый выходил в онлайн: они не тратили достаточно денег на приобретение новых клиентов, потому что не хотели увеличивая капиталовложения уменьшать стоимость акций у существующих акционеров и не думали стратегически о чате и обмене мгновенными сообщениями; в результате они так и не разработали никакого программного обеспечения для получения такого вида скрытой привязанности, какая есть у AOL. Сейчас у Juno около 3 миллионов клиентов, платящих в среднем $5.50 в месяц, в то время как у AOL около 21 миллиона клиентов, платящих в среднем $17 в месяц. Опаньки.
Компании, подобные Amazon, привлекают денежные средства почти так же быстро, как кто бы то ни было может тратить их. И для этого есть причина. Они действуют в ужасной спешке. Если в их сфере бизнеса нет конкурентов и сетевых эффектов, им лучше вырасти чрезвычайно быстро. Здесь каждый день имеет значение. И существует множество способов выиграть время в обмен на деньги (см. врезку). Почти все из них забавные.
Использовать уже готовые, меблированные офисы вместо традиционных офисных помещений. Затраты: Втрое больше. Сэкономленное время: От нескольких месяцев до года, в зависимости от состояния рынка.
Платить чрезмерно высокую зарплату программистам или предоставлять им BMW в качестве начального бонуса. Затраты: на 25% больше для технического персонала. Сэкономленное время: вы сможете заполнить все вакансии за 3 недели вместо обычных 6 месяцев.
Нанять независимых консультантов вместо наемных работников. Затраты: Втрое больше. Сэкономленное время: вы можете заставить консультантов работать немедленно.
У вас проблемы с тем, что вы не можете заставить ваших консультантов предоставлять вам то время и внимание, в которых вы нуждаетесь? Подкупайте их наличными до тех пор, пока они не станут работать только на вас.
Будьте щедрыми в деньгах при разрешении проблем. Если ваша новая звезда программирования не может закончить большое количество работы из-за того, что его семья занята постройкой нового дома и переселением, наймите высококлассных специалистов, которые сделают это за них. Если установка телефонов в ваших новых офисных помещениях длится уже вечность, купите пару дюжин сотовых телефонов. Проблемы доступа к интернету замедляют работу персонала? Просто подключитесь через пару дополнительных провайдеров. Сделайте так, чтобы консьерж, доступный всем работникам, забирал одежду из химчистки, бронировал места, договаривался о лимузинах для поездок в аэропорт и т.д.
Для некоторых компаний это может быть нормально. Для других компаний корпоративная культура является важной частью смысла существования компании. Ben and Jerry's существует, благодаря ценностным ориентирам ее основателей, которые не приняли бы рост быстрее, чем со скоростью, на которой корпоративная культура будет распространяться.
Возьмем гипотетический пример из области разработки программного обеспечения. Допустим, вы хотите проникнуть на рынок текстовых процессоров. В настоящее время этот сектор рынка, похоже, почти полностью принадлежит Microsoft, но вы видите нишу для людей, которые, по какой бы то ни было причине, совершенно не могут пользоваться текстовыми процессорами, которые постоянно "валятся" у них. Вы собираетесь сделать супер-устойчивый, обладающий признанной в отрасли надежностью текстовый процессор, который просто не будет падать, и продавать его по завышенной цене людям, жизнь которых просто зависит от текстовых процессоров. (Конечно, это преувеличение. Я сказал, что это был гипотетический пример.)
Теперь ваша корпоративная культура, вероятно, включает в себя все виды методов для написания высокоустойчивого кода: блочное тестирование, формальные проверки кода, соглашения по программированию, большие отделы по обеспечению качества, и так далее. Эти методы нетривиальны; им нужно учиться в течение определенного промежутка времени.
Пока новые программисты учатся, как писать надежный код, кто-то более опытный должен учить и наставлять их.
Как только вы попытаетесь расти так быстро, что обучение и наставничество станут невозможны, вы просто перестанете передавать эти ценности. Новые работники не будут осторожными и будут писать ненадежный код. Они не будут проверять возвращаемое значение функции malloc(), и их код будет падать в каком-нибудь замысловатом случае, о котором они никогда не подумали бы, и ни у кого не будет времени, чтобы проверить их код и научить их, как делать правильно; в результате все ваше конкурентное преимущество перед Microsoft Word рассеется.
Тихая маленькая фирмочка в Альбукерке
Согласно опыту, вы можете либо создать приятное место для работы, либо пообещать людям, что они скоро разбогатеют. Но вы должны осуществить хотя бы одно из вышесказанного, иначе вы не сможете никого нанять.
Некоторые из ваших работников прельстятся компанией с большими шансами на IPO, при котором распределяется большое количество фондовых опционов.
Такие люди будут готовы поднапрячься и проработать три или четыре года в компании, подобной этой, даже если им ненавистна каждая минута, проведенная на этой работе - потому что они видят тот самый горшочек с золотом на конце радуги.
Если ваша компания растет медленно и органично, этот горшочек может оказаться гораздо дальше. В этом случае, у вас нет другого выбора, кроме как создать такую рабочую обстановку, в которой и сама работа является наградой. Это не может быть просто 80 лихорадочных рабочих недель. Контора не может быть большим шумным помещением на верхнем этаже здания, забитым до отказа заполненными столами и тяжелыми деревянными креслами. Вы должны дать людям приличные отпуска. Люди должны быть друзьями, а не просто сотрудниками. Социологический подход в организации работы и общность интересов весьма существенны. Менеджеры должны быть хорошо информированными и особенно не донимающими людей, они не могут быть микроменеджерами Дильбертова типа. Если вы сделаете все это, вы привлечете множество людей, которые лопухнулись слишком много раз в своих мечтаниях стать миллионерами в момент очередного IPO; теперь они просто подыскивают что-нибудь приемлемое.
Проблема с моделью фирмы Amazon состоит в том, что все только и думают об Amazon. При этом существует только одна компания Amazon. Вы должны поразмыслить о тех других 95% фирм, которые потратили ошеломляющие венчурные капиталы, а потом просто разорились, потому что никто не хочет покупать их продукцию. По крайней мере, если вы последуете модели Ben and Jerry's, вы выясните, что никто не хочет покупать вашу продукцию задолго до того, как потратите сумму, равную кредитному лимиту одной карты MasterCard.
Самое худшее, что вы можете сделать
Самое худшее из того, что вы можете сделать, - это так и не решить, будет ли ваша компания следовать стратегии Ben and Jerry's или Amazon.
Если вы выходите на рынок, где отсутствует установившаяся конкуренция, эффект клиентской привязанности и сетевые эффекты, вам предпочтительнее использовать модель Amazon, иначе вы можете повторить путь компании , которая начала работать на два года раньше, чем Amazon, но никто никогда от ней не слышал. Или еще хуже, ваша компания будет как подобный привидению сайт , у которого в действительности нет шансов когда-либо превзойти eBay. (Читайте .)
Если вы приходите на установившийся рынок, быстрый рост - это потрясающий способ потратить уйму денег, как это сделала компания . Ваша наилучшая надежда состоит в том, чтобы создать что-то приемлемое и прибыльное для того, чтобы в вашем распоряжении были годы для постепенного подавления конкуренции.
Все еще не можете решить? Есть и другие вещи, которые надо обдумать. Подумайте о своих личных ценностях. Хотели бы вы иметь компанию, подобную Amazon, или компанию, подобную Ben and Jerry's? Прочтите парочку корпоративных историй - и для начинающих, даже несмотря на то, что они вопиющим образом идеализированы, и посмотрите, которая из них больше соответствует вашим коренным ценностям. На самом деле, более подходящим примером компании а-ля Ben and Jerry's является Microsoft, при этом существует множество историй этой фирмы. Фирма Microsoft была, в каком-то смысле, очень удачлива, заключив ту сделку с PC-DOS, но эта компания все время росла и была прибыльной, поэтому они могли бы ничего не делать в течение неопределенного промежутка времени в ожидании своего большого рывка.
Подумайте о соотношении ваших рисков и возмещений. Хотите ли вы предпринять попытку стать миллионером к 35 годам, даже если шансы на это таковы, что при таком раскладе лотерея выглядит как удачная сделка? Компании, подобные Ben and Jerry's, не смогут дать вам этого.
Вероятно, самое худшее , что вы можете сделать, - это решить, что вам надо быть такой компанией как Amazon, и после этого дейстовать как Ben and Jerry's (все время пребывая в неведении относительно этого). Компании, подобные Amazon, безусловно, должны выигрывать время в обмен на деньги, когда это только возможно. Вы можете полагать, что вы поступаете разумно и экономно, настаивая на том, чтобы находить только тех программистов, что работают по рыночным расценкам. Но в этом вы поступаете неразумно, потому что это будет стоит вам шесть месяцев, а не два, а эти 4 месяца могут означать, что вы пропустите сезон рождественских продаж, так что это будет стоить вам целого года, и, вероятно, сделает весь ваш бизнес-план нежизнеспособным. Вы можете считать резонным наличие версии вашего программного обеспечения для Mac, так же как и для Windows, но, пока ваши программисты обеспечат совместимость, пройдет вдвое больше времени, при этом вы получите всего лишь на 15% больше пользователей. Само собой, после этого вы уже не будете выглядеть таким умным, не так ли?
Обе модели работают, но вы должны выбрать одну и строго придерживаться ее, иначе вы обнаружите, что дела по какой-то загадочной причине идут не так, как надо, и вы совсем не знаете, почему.
В английском оригинале статья называется
Джоель Спольски - основатель , небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Искусство проведения интервью
Автор: Джоэл Сполски
Переводчик: Михаил Цукерман
Редактор: Семён Хавкин
18.10.2002
Для нашей компании (Fog Creek Software) проблема найма подходящих работников является первостепенной. Людей, работающих в области программного обеспечения, можно разделить на три группы. Первая — это , не обладающая даже основными навыками программирования. Ее представителей легко распознать и отсеять, просто посмотрев резюме и задав пару простых вопросов. Ко второй, диаметрально противоположной группе относятся — люди, способные просто так, ради интереса, за одни выходные написать на ассемблере компилятор с языка Lisp для Palm Pilot'а. А между этими двумя крайностями находится большое количество середнячков, возможно, на что-то способных. Проблема, стоящая перед нами, как раз и заключается в том, чтобы отличить суперзвезд от посредственностей, поскольку Fog Creek Software нанимает на работу только суперзвезд. Каким образом нам это удается?
Главное и единственное требование, предъявляемое к кандидату на работу в нашей компании: он должен
знать свое дело и уметь его делать.
И больше ничего. Это все, что нам нужно. Запомните и повторяйте ежедневно перед сном. Нас интересуют люди, обладающие способностями, а не конкретным набором знаний. Любые знания все равно технически устареют через пару лет, поэтому лучше нанимать людей, способных освоить новую технологию, а не просто кого-то, кто знает SQL.
Знать свое дело — понятие, которому трудно дать точное определение. Ниже мы увидим, как с помощью нескольких простых вопросов можно распознать знающего, умного кандидата.
Умение делать дело — также крайне важное качество. Знающие, но не делающие работники — умные бездельники — обычно просиживают ученую степень в больших компаниях, где их никто не слушает из-за их полной непрактичности. Они скорее станут думать об академическом подходе к проблеме, а не о выпуске продукта в срок. Их легко узнать по склонности к поиску теоретического сходства между двумя совершенно разными концепциями. Например, они могут заявить: «Таблицы — это, в сущности, частный случай языка программирования», а затем исчезнуть на неделю и написать потрясающую статью о теоретических атрибутах вычислительной лингвистики электронных таблиц как языка программирования. Круто, но бесполезно. Наконец, попадаются и деятельные дураки. Они не задумываясь делают глупости, которые кому-то потом приходится разгребать. Это превращает их в обузу для компании, так как они не только сами пользы не приносят, но и у других время отнимают. Такие работники любят копировать большие куски кода вместо создания подпрограмм, поскольку это хоть и коряво, но работает.
Важнейшее правило интервьюирования гласит:
Примите решение.
Закончив интервью, вы должны принять четкое решение. Возможных вариантов только два: нанимать или не нанимать. Повернитесь к компьютеру и отправьте сообщение рекрутеру. Тема сообщения — имя кандидата. Первая строка — нанимать или не нанимать. После этого обоснуйте свое решение в двух абзацах. Других вариантов быть не может. Никогда не говорите: «Нанимать, но не в мою группу». Это невежливо, так как предполагает, что кандидат, недостаточно умный для работы с вами, подойдет этим бездарям из другой группы. Вместо «Нанимать, но не в мою группу» напишите, не задумываясь, «не нанимать», и все будет в порядке. Даже если вы столкнулись с прекрасным специалистом в одной конкретной области, но для вас не подходящим — это значит «не нанимать». Обстоятельства меняются настолько часто, что ценность представляют люди, способные работать везде. Если вам попадется узкий специалист, просто-таки блестяще знающий SQL, но не способный обучиться чему-то другому, не нанимайте его. У таких людей в нашей фирме нет будущего.
Никогда не говорите «может быть» или «не уверен». Не уверены — не нанимайте. Это проще, чем кажется. Не уверены? Скажите нет. И ещё, если вы занимаете выжидательную позицию, это тоже значит «не нанимать». Никогда не говорите: «Хорошо, я думаю, мы его возьмем, хотя есть некоторые сомнения насчет...». Это тоже «не берем».
В процессе интервьюирования важно помнить следующее: лучше отказаться от хорошего кандидата, чем нанять плохого. Плохой работник будет стоить кучу денег, усилий и времени, которое другие люди потратят, исправляя его ошибки. В случае любых сомнений лучше сказать «не берем».
Проводя интервью, не думайте, что если вы откажете слишком многим, наша фирма не найдет себе работников. Это не ваша проблема. Это проблема рекрутеров и отдела кадров, это проблема Джоэля, но никак не ваша. Спросите себя, что хуже — если мы станем большой конторой с кучей дураков или останемся маленькой, но высококачественной фирмой? Конечно, важно искать хороших сотрудников, и все должны рассматривать это как часть своей работы. Но в процессе интервью лучше думать, что у нас есть куча классных кандидатов. Никогда не снижайте стандартов, как бы ни сложно было найти хороших работников. Но как же принять это самое решение? Нужно постоянно спрашивать себя во время интервью: А дело он знает? Он способен нормально делать дело? Чтобы получить ответ, нужно задавать правильные вопросы. Вот вам, смеха ради, отвратительный вопрос для интервью: «В чем разница между varchar и varchar2 в Oracle 8i?» Задавать такой вопрос совершенно бессмыссленно: между людьми, знающими эту бесполезную мелочь, и людьми, действительно нужными нашей компании, нет ни малейшей корреляции. Кого волнует, в чем эта разница? Ответ ищется в Интернете за 15 секунд! Правда, есть вопросы и похуже; к ним я еще вернусь.
Теперь перейдем к самому интересному — собственно вопросам для интервью. Я начал составлять свой собственный список во время моей первой работы в Майкрософте. Существуют сотни знаменитых вопросов от Майкрософт. У каждого есть свои любимые вопросы. Вам тоже нужно разработать свой набор вопросов и собственный стиль интервью, это поможет вам принимать правильные решения. Вот некоторые приемы из моей практики. Перед интервью я читаю резюме кандидата и набрасываю план интервью на листке бумаги — просто список вопросов, которые я собираюсь задать. Вот типичный план интервью кандидата на позицию программиста:
Встуление Вопрос о последнем проекте, в котором участвовал кандидат Вопрос на засыпку Функция на Cи Вы довольны? Вопрос по дизайну Вопрос-провокация Есть ли у вас вопросы?
До интервью я стараюсь избегать всего, что может создать у меня предвзятое мнение о кандидате. Если вы сочтете кого-то умным еще до того, как он войдет в комнату, только потому, что он Ph.D. из MIT, ничто из сказанного им за час не перевесит этой предвзятости. Если вы заранее решили, что он — полный дурак, ничто вас не переубедит. Интервью подобно чувствительным весам: очень трудно судить о ком-либо на основании часовой беседы. Но если вы что-то узнаете о кандидате до интервью, на одной чаше весов появится здоровенная гиря, и интервью потеряет смысл. Однажды прямо перед интервью к нам в офис зашел рекрутер и сказал: «Этот парень вам очень понравится!» Это меня полностью выбило из колеи! Я должен был сказать что-то типа «если вы так уверены, что он мне понравится, что ж вы его сразу не наняли и не сэкономили мне время ?» Но я был молод и наивен и пошел его интервьюировать. Когда он говорил что-нибудь не очень умное, я думал: «Ну, это исключение, подтверждающее правило». Я смотрел на все его ответы через розовые очки. В итоге я сказал «берем», хотя это был никудышный кандидат. И что бы вы думали ? Все остальные, интервьюировавшие его, сказали «не берем»! Мораль: не слушайте рекрутеров, не спрашивайте никого о кандидате и не говорите о нем с другими интервьюерами до момента принятия независимого решения. Это и есть научный метод!
Фаза вступления в интервью должна расслабить кандидата. Я трачу около 30 секунд, рассказывая кандидату, кто я такой и как буду проводить интервью. Я всегда заверяю кандидата, что нас интересует его подход к проблеме, а не его конкретные ответы. Кстати, в процессе интервью не стоит сидеть через стол от кандидата, поскольку это создает формальную преграду и мешает ему расслабиться. Лучше поставить стол к стене или обойти стол и сесть рядом с кандидатом. Интервью при этом проходит лучше, поскольку он меньше нервничает.
Вторая часть — это вопрос о каком-нибудь проекте, в котором кандидат недавно участвовал. Если он только что окончил институт, спросите о теме диплома, о курсовом проекте или о предмете (не обязятельно компьютерном, так даже интереснее), который ему больше всего понравился. При интервьюировании опытных кандидатов можно спросить о предыдущем месте работы. В ответе на этот вопрос меня волнует только одно: энтузиазм. Вот хорошие признаки при обсуждении предыдущей работы:
Кандидат приходит в возбуждение; говорит быстрее и энергично жестикулирует. Это показывает, что если его что-то интересует, он будeт подходить к делу с энтузиазмом. На свете полно людей, которых вообще ничего не волнует. Даже отрицательные эмоции могут быть хорошим знаком. «У предыдущего начальника я работал над инсталляцией Второй Версии Такой-то Программы, но он был полный дурак!» Это хорошие, нужные нам кандидаты. Плохих кандидатов не волнует вообще ничего, их не удастся расшевелить в течение всего интервью. Очень хорошо, если, рассказывая о чем-то, кандидат вообще забудет на некоторое время, что он на интервью. Иногда кандидат очень нервничает по поводу самой ситуации интервью. Это нормально, и на это нужно делать поправку. Но вот он приходит в неописуемый восторг при разговоре о Монохроматическом Вычислительном Искусстве, и его нервозности как не бывало. Отлично. Нам нужны люди, которых что-то может взволновать. (Чтобы увидеть образчик Монохроматического Вычислительного Искусства, попробуйте выключить монитор). Кандидат аккуратно и хорошо объясняет. Я отказывал кандидатам, которые, рассказывая о предыдущем проекте, не могли объяснить его суть словами, понятными простому смертному. Студенты часто предполагают, что каждому известна теорема Бейтса, или что каждый знает, в чем заключаются аксиомы Пеано. Если они примутся за это, остановите их и скажите: «Простите, но не могли бы вы, хотя бы в качестве упражнения, объяснить это словами, понятными моей бабушке?» После этого многие все же продолжают использовать жаргон, не в состоянии говорить понятным языком... Если проект, о котором рассказывает кандидат, был групповым, поищите черты лидера. Кандидат может сказать: мы работали над А, но начальство сказало Б, а клиент сказал В. «Что же вы сделали?» — спрошу я. Хороший ответ — это, например: «Ну, я собрал остальных и мы написали предложение...» Плохой ответ может выглядеть так: «Это была безвыходная ситуация... Что ж я тут мог сделать...» Помните: знает свое дело и умеет его делать. Хороший способ определить умение делать дело — посмотреть, доводил ли он до конце свои прошлые проекты. Например, можно прямо спросить кандидата, проходилось ли ему выступать в роли лидера и добиваться решения стоявших перед ним проблем.
Третьим в списке идет вопрос на засыпку. Это забавно. Смысл в том, чтобы задать вопрос, на который у человека не найдется ответа — просто чтобы посмотреть, что он будут делать. Сколько окулистов в Сиэтле? Сколько тонн весит Вашингтонский Монумент? Сколько бензоколонок в Лос-Анджелесе? Сколько настройщиков роялей в Нью-Йорке?
Умный кандидат поймет, что вы не издеваетесь над ним, и с энтузиазмом возьмется за поиски нужного ответа. «Что ж, в Лос-Анджелесе живет около 7 миллионов человек; у каждого в среднем 2,5 машины...» Конечно, даже если он в корне неправ, это ничего не меняет. Важно, чтобы он с энтузиазмом относился к поискам ответа. «Ну, машина заправляется минуты четыре, на заправке около 10 колонок, а работает она часов 18 в день...». Он может попытаться найти ответ исходя из площади города. Иногда кандидаты удивляют своей изобретательностью, а иногда просят телефонный справочник Лос-Анджелеса. Это всё хорошие признаки. Не слишком умные кандидаты начинают волноваться и расстраиваться. Они смотрят на вас, как на пришельца с Марса. Их приходится направлять. «Вот если бы вы строили новый город размером с Лос-Анджелес, сколько бензоколонок вы запланировали бы?» Можно давать маленькие подсказки. «Сколько времени нужно, чтобы залить бак?» Не слишком умных кандидатов придется тащить волоком, в то время, как сами они будут тупо пялиться на вас, и ждать, когда вы их спасете. Такие люди не умеют самостоятельно работать, и нам они не нужны.
Из программистских вопросов мне больше всего нравится попросить написать небольшую функцию на Си. Вот обычные задачи:
Перевернуть строку, не пользуясь дополнительным буфером. Перевернуть связный список. Посчитать все ненулевые биты в байте. Бинарный поиск. Найти в строке самую длинную подстроку из одинаковых букв. atoi
itoa (отличное задание, поскольку им придется использовать стек или strrev)
Не стоит задавать задачи, требующие более 5 строк кода; на это просто нет времени.
Рассмотрим эти задачи подробнее.
#1: Переворот строки на месте. Каждый кандидат, с которым я имел дело, первый раз делал это неверно. Все без исключения пытались выделить новый буфер в памяти и переворачивать строку в нем. Вопрос, кто выделяет буфер? И кто его освобождает? Задавая этот вопрос множеству кандидатов, я обнаружил любопытную вещь. Большинство людей, думающих, что они знают Си, на самом деле не понимают работы памяти или указателей. Это до них просто не доходит. Удивительно, как эти люди работают программистами, но ведь работают же! Вот несколько способов судить о кандидате на основании этого вопроса:
Быстро ли работает его функция? Посмотрите, сколько раз вызывается strlen. Я видел алгоритмы порядка O(n^2) для strrev, хотя должно быть O(n) — потому, что strlen вызывался в цикле снова и снова. Используют ли он указатели? Это хороший признак. Многие программисты на Си просто не знают, как заставить работать указатели. Я, как правило, не отказываюсь от кандидата из-за отсутствия у него какого-то навыка. Однако я обнаружил, что понимание указателей в Си — это не навык, а способность. В начале первого курса на факультете кибернетики набирается человек 200 вундеркиндов, писавших в четырехлетнем возрасте игрушки для Atari 800 на BASIC'е. Они хорошо проводят время, изучая Паскаль, но в один прекрасный день профессор заводит речь об указателях, и они внезапно перестают понимать. То есть абсолютно. 90% потока переходит на отделение политологии, обьясняя это тем, что на кибернетике мало симпатичных студенток. На самом же деле, по неизвестной причине часть человечества просто рождается без того отдела мозга, который понимает указатели. Указатели — это не навык, а способность, требующая особого мышления, и некоторые люди им просто не обладают.
Третья задача показывает, насколько хорошо они учили побитовые операторы в Си... но это уже навык, а не способность, и тут им можно помочь. Интересно посмотреть, как они пишут программу, пересчитывающую все биты в байте, а потом попросить сделать это гораздо, гораздо быстрее. Сообразительный кандидат создаст поисковую таблицу (там ведь всего 256 значений), заполняемую только один раз. С хорошим кандидатом можно даже завести интересную беседу о компромиссах между скоростью выполнения и требуемой памятью. Поднажмите. Скажите, что не хотите тратить время на создание таблицы при инициализации. Очень умные кандидаты могут даже предложить схему кэширования, где биты считаются при первом использовании и сохраняются в таблице, чтобы не пересчитывать их в следующий раз. А самые умные попробуют изобрести способ вычисления значений таблицы, используя для этого некие расширенные методы программирования. Наблюдая, как кто-нибудь пишет код, используйте следующие полезные приемы:
Непременно скажите кандидату, что вы понимаете, как трудно писать код без редактора, от руки, и чтобы он не переживал, что его каракули будут не так легко разобрать.
Признак хорошего программиста: он имеет привычку сразу ставить фигурные скобки { и } и писать между ними. У него обычно есть своя, пусть и примитивная, система присвоения имен. Хорошие программисты обычно используют короткие имена для индексов цикла. Если такая переменная названа CurrentPagePositionLoopCounter, значит, немного кода этот человек в своей жизни написал. Иногда встречается программист на Си, пишущий что-то типа if((0==strlen(x)), помещая константу слева от ==. Это очень хороший признак, означающий, что он уже столько раз попадался на путанице между = и ==, что выработал в себе привычку, исключающую подобное.
Хорошие программисты думают перед тем, как писать программу, особенно если в коде используются указатели. Например, если нужно перевернуть связный список, хороший кандидат непременно нарисует сбоку, откуда и куда идут указатели. Он просто вынужден это сделать, ибо человек не в силах написать код, переворачивающий связный список, не нарисовав маленькие квадратики со стрелочками между ними. Плохой программист начнет писать сразу.
Скорее всего, в их коде будут ошибки. И тут мы подходим к вопросу номер 5: Нравится ли вам ваш код? Альтернативный вариант: «Ну, и где здесь ошибка?» Типичный Вопрос С Открытым Концом. Все программисты ошибаются, в этом нет ничего особенного, но нужно уметь находить свои ошибки. При работе с текстами очень часто забывают завершить новую строку нулем. Почти всегда легко ошибиться на единицу при подсчетах индексов. Иногда забывают точку с запятой, или функции работают некорректно со строкой нулевой длины или вызывают GPF при неудачном обращении к malloc... Очень, очень редко попадается кандидат, с первого раза не сделавший ни одной ошибки. В этом случае все еще забавнее. «У вас тут ошибка!» — после чего он внимательно изучает написанное, а вы смотрите, может ли он мягко и дипломатично заявить, что его код абсолютно верен. В общем, всегда полезно спросить кандидата, доволен ли он своей программой, прежде чем двинуться дальше.
Далее, номер 6: вопрос по дизайну. Попросите кандидата что-нибудь спроектировать. Джейб Блюменталь (Jabe Blumenthal), первый дизайнер Excel'я, любил просить кандидатов спроектировать домик. Он говорил, что встречались кандидаты, немедленно рисующие квадрат. Квадрат! Это были явные кандидаты на отсев. Что, собственно, нам нужно от этого вопроса?
Хороший кандидат попытается вытянуть из вас побольше информации. Для кого нужен дом? Я принципиально не приму на работу кого-то, занимающегося проектированием и не спрашивающего, для чего. Однажды меня это так возмутило, что я прервал кандидата и сказал: «Вы забыли об этом спросить, но это дом для семейства слепых жирафов.» Не очень умные кандидаты считают, что проектирование сродни рисованию: вот чистая доска, можно делать, что захочешь. Умные кандидаты понимают, что речь идет о сложной последовательности компромиссов. Серьёзный вопрос по дизайну — спроектировать урну для угла улицы. Нужно, чтобы ее было легко опорожнить, но невозможно украсть; чтобы в нее было легко бросать мусор, но из нее ничего не должно вылетать в ветреный день; урна должна быть прочной, но дешевой. В некоторых городах нужно проектировать урну так, чтобы террористы не могли подложить в нее бомбу. Творчески мыслящие кандидаты часто удивляют интересными, неочевидными ответами. Один из моих любимых вопросов — придумать хранилище специй для слепых. Кандидаты непременно размещают надпись азбукой Брайля в каком-нибудь месте перечницы, и чаще всего сверху, по множеству причин, которые вы узнаете, задав этот вопрос раз сто. А один из моих кандидатов решил, что лучше поместить специи в выдвигающиеся ящички, поскольку Брайля удобнее читать горизонтально. Это был впечатляющий выход за пределы обычного видения проблемы. Впоследствии этот кандидат стал одним из ведущих менеджеров в команде Excel. Следите за завершением обсуждения — это показатель способности решать проблемы. Иногда кандидаты колеблются, не в силах принять решение, или пытаются обойти трудные вопросы. Иногда они оставляют вопросы без ответа и пытаются двигаться дальше. Хорошие кандидаты стараются двигаться вперед естественным путем, даже если вы пытаетесь сбить их с толку. Если разговор начинает двигаться кругами, и кандидат заявляет нечто вроде «Ну, так мы можем говорить целый день, но нужно двигаться дальше, поэтому давайте примем решение Х», это хороший знак.
Что приводит нас к номеру 7, вопросу-провокации. В процессе интервью нужно дождаться, пока кандидат не скажет что-нибудь абсолютно, бесспорно верное. Тут надо сказать «минуточку, минуточку» и пару минут поиграть в адвоката дьявола. Поспорьте с ним, твердо зная, что он прав. Получается довольно забавно.
Слабые кандидаты сдаются. Не берем. Сильные кандидаты находят способ убедить вас. У них для этого найдется целый набор способов Карнеги. «Возможно, я вас не совсем понял...» — скажут они. Но будут стоять на своем. Берем.
Известно, что во время интервью стороны находятся в неравном положении. Есть риск, что кандидат просто не отважится спорить с вами. Но хорошие кандидаты, как правило, мгновенно «заводятся» и забывают, что они на интервью. Они непременно постараются вас переубедить. Это и есть люди, которые нам нужны.
Последний вопрос к кандидату — есть ли у него вопросы. Некоторые пытаются посмотреть, насколько умны вопросы, задаваемые кандидатом. Это стандартная техника из руководства по проведению интервью. Для меня его вопросы не имеют значения. Во-первых, к этому моменту я уже принял решение. Во-вторых, за день кандидат должен поговорить с 5-6 людьми, и трудно задать 5-6 людям разные умные вопросы. Так что если у кандидата нет вопросов, это хорошо.
В конце интервью я обязательно оставляю пять минут на рекламу нашей фирмы. Это очень важно, даже если вы не собираетесь брать этого человека на работу. Если вам повезло найти действительно хорошего кандидата, следует сделать все возможное, чтобы он захотел работать в Fog Creek. Если же это плохой кандидат, нужно, чтобы он ушел в восторге от компании. Смотрите на это так: те, кого вы интервьюируете, — не только потенциальные сотрудники, но и клиенты. Они — ваши потенциальные рекрутеры. Если они сочтут вашу компанию классным местом, то приведут к вам своих друзей.
Да, я обещал дать вам примеры плохих вопросов.
Прежде всего, исключите запрещенные вопросы. Все, связанное с расой, религией, полом, страной происхождения, возрастом, военной обязанностью, статусом ветерана войны, сексуальной ориентацией или физическим состоянием, является противозаконным. Если в резюме кандидата написано, что он в 1990-м году служил в армии, не нужно — даже для поддержания разговора — спрашивать, участвовал ли он в "Буре в Пустыне". Это противозаконно. Если в резюме сказано, что кандидат учился в Хайфском Технионе, не нужно — даже мимоходом — интересоваться, израильтянин ли ваш собеседник. Это противозаконно. Довольно интересное обсуждение запрещенных вопросов можно найти (все остальные вопросы на этом сайте на редкость неудачные).
Далее, старайтесь избегать любых вопросов, создающих впечатление дискриминации по тому или иному признаку или повышенного внимания к тому или иному признаку. Вот хороший пример: если вы спросите, замужем ли ваша собеседница и есть ли у нее дети, у нее может создаться ошибочное впечатление, что в вашей компании косо смотрят на семейных сотрудников, особенно женщин, так как они якобы уделяют меньше времени работе и в любой момент могут уйти в декретный отпуск.
И последнее: не задавайте голововоломных вопросов, например, как сложить 4 равносторонних треугольника из 6 спичек. Знает кандидат верный ответ или нет — вы все равно ничего не узнаете о его умственных или деловых качествах.
Интервью — это скорее искусство, чем наука, но если держать в голове принцип «знает свое дело и умеет его делать», все упрощается. Если получится, поговорите со своими коллегами об их любимых вопросах и об ответах, которые они ожидают услышать. В кафетерии 16-го корпуса в Редмонде это уже много лет любимая тема для обеденных разговоров.
Примечания переводчика.
MIT — (Массачусетский Технологический Институт), один из лучших технических ВУЗов Америки. Ph.D. (от латинского Philosophiae Doctor, Доктор философии) — ученая степень в какой-либо области, примерный аналог российской степени кандидата наук. Говоря о запрещенных вопросах, автор имеет в виду вопросы, юридически неправомерные с точки зрения американских законов. — Технологический Институт в городе Хайфа, один из лучших ВУЗов Израиля. Редмонд — город, в котором находится фирма Microsoft.
Примечания редактора.
Рекрутер — человек, по зову службы или сердца занимающийся наймом на работу. GPF — ошибка, хорошо знакомая имевшим дело с семейством операционных систем под общим названием Microsoft Windows. Вплоть до конца прошлого столетия, сообщение об этой ошибке регулярно приветствовало работников мыша и клавиатуры. Со временем, надо отметить, частота её появления заметно снизилась, что и натолкнуло на мысль о необходимости данного комментария. Теорема Бэйтса. В оригинале, возможно, опечатка, и в виду имелась значительно более известная . Конечно, на суть это не влияет. А вы знаете, в чём заключаются ?
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
"Я начальник - ты дурак" и команда клоунов
Автор: Джоэл Сполски
Переводчик: Маргарита Исаева
Редактор: Дмитрий Казачков
23 марта 2000
Недавно я размышлял о том, почему так здорово было работать в Microsoft, и почему так противно в Juno. Поначалу, я объяснял все разницей в стиле жизни на восточном/западном побережье, но теперь мне кажется, что не все так просто.
Одной из наиболее важных составляющих успеха Microsoft было стремление Билла Гейтса нанимать только лучших. Если вы нанимаете только отличников, говорил он, они, в свою очередь, будут нанимать отличников. Но если вы нанимаете хорошистов, они наймут троечников, и тогда пиши пропало. Определенно, в Microsoft все так и было. Целые подразделения Microsoft были заполнены замечательными людьми; и бизнес у них всегда процветал (Office, Windows, и инструменты для разработчиков). Но существовали и подразделения, дела в которых шли не так хорошо: MSN раз за разом терпел неудачу; Microsoft Money потребовалась вечность, чтобы начать работать, а у работников справочной службы Microsoft вообще ветер гулял в голове. Очевидно, что в каждом из этих случаев капитан-хорошист укомплектовал команду игроками-троечниками, и ни к чему хорошему это не привело.
Поэтому: бери на работу людей, которые знают свое дело и уметь его делать (см. ). Это настолько важно, что у нас про это есть целая веб-страница, и для PaxDigita это одна из важнейших целей. Когда такая стратегия применялась в Microsoft, она давала хорошие результаты.
Когда я первый раз был на интервью в Juno, я не был уверен, что мне там понравится. Их программы выглядели как-то несерьезно. Вся компания попахивала духом флибустьеров с Уолл-стрит, которые услыхали, что Интернет — это круто, и решили, что и им надо сунуть туда свой нос. Так что я позвонил им и сказал: "Вы знаете, я не уверен, что хочу у вас работать, но я бы хотел побольше о вас узнать."
В своем типичном высокомерном стиле, они, как ни в чем не бывало, продолжали прогонять меня через строй интервьюеров, и я должен был доказывать, что достаточно хорош, чтобы у них работать. Сперва меня это немного разозлило, потому что я еще сам не решил, нужна ли мне эта работа. Но потом я подумал, что компания, у которой такие строгие критерии найма, просто обязана быть укомплектованной отборными интеллектуалами. Это одно заставило меня согласиться. Наверняка Juno (вплоть до Д.Шоу (D.E. Shaw), отца-основателя) состояло из одних гениев. Секретарши были с учеными степенями. Там было много таких людей как Эрик Каплан (Eric Caplan), бывший профессор из Чикаго, который сидел и с божьей помощью писал техническую документацию для интранет. Можете здесь порассуждать об избытке образования.
Пару лет в Juno я был вполне счастлив. Это была не работа, а сказка. (У меня даже брали интервью для сайта, который назывался dreamjobs.com где я рассказывал, как все в Juno сказочно). Одно было странно — примерно через год меня повысили и дали в подчинение ровно двух людей из тех шести, что были в моей команде. Вообще-то, у среднестатистического менеджера в Juno как раз и было примерно двое подчиненных, потрясяюще вертикальная организация по любым меркам.
Следующая странность, которую я заметил, была та, что люди увольнялись пачками. В загадочном мире Силиконовки это не было чем-то необычным. Загадкой оставалось то, всякий раз причина для увольнения была одна и та же: никто не видел перспективы повышения в рамках компании.
Что мы там имели, так это компанию, настолько вертикально и иерархично построенную, насколько воображения хватало, с 50 начальниками из 150 человек числящихся в штате, а народ жаловался на осутствие перспектив на повышение.
В чем же дело?
Почему-то в Microsoft множество людей на низшей ступени иерархической лестницы были вполне довольны своей работой и были бы счастливы продолжать в том же духе и дальше. Тогда как в Juno люди на той же самой ступеньке быстро теряли энтузиазм и собирались увольняться, потому что не надеялись на повышение.
Я думаю, вся разница в корпоративной культуре, в частности, в том, как работает руководство.
В Microsoft руководство неукоснительно придерживалось политики "руки прочь!" Обычно, у каждого был свой участок работы, и это был в полном смысле его участок. Менеджеры не пытались давать указания, а видели свою задачу в том, чтобы бегать вокруг и убирать мебель с дороги, для того чтобы их люди могли без помех делать свое дело.
Было несколько замечательных примеров такой организации дела. Менеджеры никогда не брали на себя решение конфликтов. Как это обычно происходило: дизайнер вступал в спор с программистом по поводу того, как должна выглядеть очередная примочка. Они спорили до хрипоты, обсуждая проблему битый час, и в конце концов, ни до чего не договорившись, топали в кабинет начальника за окончательным решением. Итак, в комнате три человека: дизайнер, программист, и начальник. Кто из них знает о проблеме меньше всех? Скорее всего начальник — тот, которого только что пригласили для Разрешения Конфликта. В Microsoft начальник отказался бы принимать решение. При прочих равных, он меньше всех знает о проблеме. Обычно начальник заставлял дизайнера и программиста решать самих, что они, в конце концов, и делали.
В Juno все было с точностью до наоборот. Участки работы были ничьи, люди просто работали на них, и руководители разных уровней с удовольствием запускали руки в каждый стряпающийся пирог, раздавая указания направо и налево в стиле, который я стал называть порулил и убегай, потому что начальники появлялись на горизонте вероломно, отдавали глупые распоряжения как именно все, черт побери, должно было сделано, без какого-либо предварительного размышления, и покидали комнату, оставляя всех собирать осколки. Наиболее вопиющий пример демонстрировал сам директор компании, который регулярно запрашивал распечатки всех экранов, уносил их домой и правил красными чернилами. Иногда его исправления были полезны (когда он находил грамматические и орфографические ошибки), в остальных случаях они демонстрировали только полное непонимание того, что просходит на этих экранах и почему на них написано то, что на них написано. Месяцами позже, на совещаниях говорилось: "Чарльзу [это директор] не нравятся выпадающие списки", из-за когда-то чего-то им отредактированного без всякого понимания сути, и это воспринималось как последнее слово. С этим воображаемым Чарльзом нельзя было не согласиться, потому что его там не было; он не участвовал в разработке дизайна иначе, кроме как методом "порулил и убегай". Блин.
Стиль управления "порулил и убегай" — это только один из симптомов того, что я бы назвал стилем "Делай, как велено" ... прямо по инструкции "Дженерал Моторс" 1953 года. В компании, особо увлеченной политическими играми, он превращается в худший вариант — игру в " Я начальник – ты дурак ". Этот стиль совершенно неприемлем, он бесит людей, он заставляет лицо с наименьшей информацией принимать решение, и он мешает компании использовать таланты нанятых ею людей. Если компания, такая как Juno, умудрилась нанять самых лучших, самых талантливых, то она проматывает потрясающий потенциал, а люди ходят злые, как черти.
Когда же стиль управления "Я начальник – ты дурак" приемлем? Ну например, он может пригодиться, если ваша компания представляет собой команду клоунов — то есть действительно состоит из неквалифицированных дебилов, которых нужно пасти. Что-то вроде того лечебно-трудового корпуса, который собирает мусор в Центральном Парке. Софтверные же компании — это не стадо баранов, и стиль "Я начальник – ты дурак" тут не поможет.
Культура в PaxDigita
Вот поэтому для меня так важно привить правильную "руки прочь!" культуру управления в PaxDigita. В общем и целом:
Каждый имеет свой участок работы. Если он твой, он твой. Если начальник, или кто-то еще, желает пролить свет на то, как на участке должны идти дела, он должен разговаривать с хозяином. Хозяину принадлежит последнее слово.
Каждое решение принимается тем, у кого информация.
Управление максимально "плоское". В идеале, руководителю должно быть некогда запускать руки в дела подчиненных. Возможно, вам будет интересно почитать про , на котором работают 170 человек, и все 170 подчиняются непосредствено директору завода.
В результате, мы получаем демократическую культуру, в которой каждый управляет компанией. Изо дня в день люди в PaxDigita обходятся без руководителя — своими руками они водят сами.
В английском оригинале статья называется Command and Conquer and the Herd of Coconuts
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Как Microsoft проиграла битву за API
Автор: Джоэл Сполски
Переводчик: Алексей Бушмин
10. 01. 2005
Перед вами модная теория: «Microsoft-у конец. Как только Linux продвинется в своем набеге на десктопы, и web-приложения заменят настольные приложения (desktop application), могучая империя падет».
И хотя существует часть правды в том, что Linux представляет большую угрозу для Microsoft, предсказания о падении компании из Рэдмонда, по меньшей мере, преждевременны. У Microsoft невероятное количество денег в банке, и они до сих пор невероятно прибыльны. Падение будет долгим. Они могут халтурить десятилетие, прежде чем попадут в зону относительной опасности, и кто знает… в последнюю минуту они могут реинкарнироваться в компанию по производству мороженого. Поэтому не торопитесь списывать их со счетов. В начале 90-х все думали, что с IBM покончено: мейнфреймы стали историей. Тогда же Роберт Крингли предсказал, что эра мейнфреймов закончится 1 января 2000 года, когда все программы на COBOLе заклинит, а вместо исправлений этих приложений, чьи исходники, как говорят, давно потеряны, легче будет их переписать на клиент-серверной платформе.
Хорошо, допустим. Мейнфреймы до сих пор с нами, ничего не произошло 1 января 2000 года, а IBM перестроилась в большую, технологически всеядную, консалтинговую компанию, производящую даже . Так что теория кончины Microsoft, выведенная из экстраполяции по малому количеству точек, является чрезмерной гиперболизацией.
Впрочем, существует мало понимаемый и в целом незамеченный феномен: стратегический бриллиант короны Microsoft – Windows API – потерян. Краеугольный камень монополии и невероятной прибыли от продаж Windows и Office, фактически обеспечивающих львиную долю в доходах Microsoft и покрывающих огромное число неприбыльных и малоприбыльных линеек продуктов, – Windows API –больше не интересен разработчикам. Курица, которая несла золотые яйца, еще не мертва, но уже смертельно больна, и это никто еще не заметил.
А теперь, позвольте мне извиниться за насыщенность и помпезность предыдущих абзацев. Похоже я начинаю выглядеть как писатель передовиц, который продолжает и продолжает кричать о стратегическом активе Microsoft: Windows API. Доказательство моих слов займет несколько страниц. Пожалуйста, не делайте никаких умозаключений, пока я не объясню, о чем я говорю. Это будет длинная статья. Мне понадобиться объяснить, что такое Windows API, продемонстрировать, почему это наиболее важный стратегический актив Microsoft . Я должен объяснить, как он был потерян, какие будут последствия. Но так как я говорю о долгосрочных тенденциях, я вынужден буду гиперболизировать и обобщать.
Разработчики, разработчики, разработчики, разработчики
Помните определение операционной системы? Это нечто, управляющее ресурсами компьютера так, что программы могут запускаться и работать. Людям в действительности наплевать на операционную систему, им не наплевать на те приложения, которые операционная система позволяет запускать. Текстовые редакторы. Интернет-пейджеры. Электронная почта. Счета к уплате. Веб-сайты с картинками Paris Hilton. Сама по себе операционная система не так полезна. Люди покупают операционные системы из-за полезных приложений, работающих на этой операционной системе. Следовательно, самая полезная операционная система та, на которой запускается наибольшее количество полезных приложений.
Логическое заключение состоит в том, что если вы пытаетесь продавать операционную систему, то вам необходимо сделать так, чтобы разработчики программного обеспечения захотели писать программы для вашей операционной системы. Поэтому Стив Баллмер прыгал по сцене и кричал: «Разработчики, разработчики, разработчики, разработчики». Это так важно для Microsoft, что единственная причина, из-за которой средства разработки программного обеспечения не раздаются бесплатно, заключается в том, что они не хотят случайно перерезать кислород разработчикам конкурирующих инструментов разработки (хорошо, тем, которые остались), так как разнообразие инструментов разработки, доступных для их платформы, делает ее куда более привлекательной для разработчиков. Но на самом деле они хотят раздавать. Благодаря их программе вы можете получить пять наборов MSDN Universal (иначе известных как «практически все продукты Microsoft, исключая Flight Simulator») всего за 375$. Компиляторы командной строки для языков .NET включены с бесплатными библиотеками .NET … тоже бесплатно. Компилятор С++ теперь . Что угодно для поощрения разработчиков работать под .NET и ликвидации таких компаний как Borland.
Почему Apple и Sun не могут продавать компьютеры
Да, это немного глупо: конечно Apple и Sun могут продавать компьютеры, но не на двух наиболее прибыльных рынках, а именно на рынках корпоративных и домашних пользователей. Aplle до сих пор где-то там внизу, с очень маленьким процентом рынка (Пожалуйста, поймите, что я говорю о больших числах, и следовательно, когда я говорю «никто», я на самом деле имею в виду «меньше чем 10 000 000 людей» и так далее и так далее).
Почему? Потому что на компьютерах Apple и Sun не работают программы для Windows, или, если работают, то в режиме дорогой и не безупречной эмуляции. Помните, что люди покупают компьютеры для программ на которых они работают, а для Windows настолько больше программного обеспечения, чем для Mac, что очень трудно быть пользователем Mac. Вот почему Windows API такой ценный актив Microsoft.
Врезка: Что такое «API»?
Если вы пишите программу, скажем текстовый редактор, и вы хотите высветить меню или записать файл, вы должны попросить операционную систему сделать это за вас, используя очень специфический набор вызовов функций, который различается на каждой операционной системе. Эти вызовы функций называются API: это интерфейс, который операционная система, например Windows, представляет разработчикам приложений, строящим текстовые процессоры, электронные таблицы и всякую всячину. Это набор тысяч и тысяч функций и подпрограмм, которые программисты могут использовать, чтобы заставить операционную систему делать такие интересные вещи как высвечивание меню, чтение и запись файла, или более эзотерические вещи, например, выяснить, как произнести конкретную дату по сербски, или черезвычайно сложное задание – вывести веб-страницу в окно. Если Ваши программы используют вызовы API для Windows, то они не будут работать в Linux, у него другие вызовы API. Иногда они делают примерно одинаковые вещи. По этой причине программы для Windows не запускаются под Linux. Если Вы хотите заставить Windows-программу работать под Linux, то вы должны заново реализовать весь Windows API, который состоит из тысяч сложных функций: это все равно, что написать Windows заново, что заняло у Microsoft тысячи человеколет. И если вы сделаете одну маленькую ошибку или упустите одну функцию, в которой нуждается приложение, то эта программа вылетит по ошибке.
(Я знаю, знаю, на этом месте 2,3% мира – пользователи Macintosh – разогревают свои почтовые программы, чтобы послать мне уничтожающее письмо о том, как они любят свои Mac’и. Еще раз: я говорю о больших цифрах и обобщаю, так что не тратьте свое время. Я знаю, как Вы любите свои Mac’и. Я знаю, что там есть все, что Вам нужно. Я люблю Вас, но Вы всего лишь 2,3% мира, и статья не про Вас).
Две силы в Microsoft
В Microsoft есть два противостоящих лагеря, я их буду называть лагерь Реймонда Чена и лагерь журнала MSDN.
Реймонд Чен – разработчик в команде Windows с 1992 года. Его веблог набит детальными техническими историями о порядке вещей в Windows, даже глупые вещи имеют под собой веские основания.
Больше всего на веблоге Реймонда впечатляет о , приложенных командой разработки Windows для поддержания обратной совместимости.
«Взгляните с точки зрения покупателя. Вы купили программы X, Y и Z. Затем вы обновились до Windows XP. Теперь ваш компьютер внезапно зависает, и программа Z вообще не работает. Вы скажите своим друзьям: «Не обновляйтесь до Windows XP. Она внезапно зависает и не совместима с программой Z». Будете ли вы дебажить вашу систему, чтобы определить, что программа X причина зависаний, а программа Z не работает, потому что использует недокументированные сообщения Windows? Конечно нет. Вы вернете коробку с Windows XP и получите обратно деньги. (Вы купили программы X, Y и Z несколько месяцев назад. 30-дневный срок возврата уже для них не действует. Единственное, что вы можете вернуть, это Windows XP.)»
Я впервые услышал об этом от одного из разработчиков популярной игры SimCity, который поведал мне о критической ошибке в их программе: она использовала память сразу после ее освобождения. Главное табу, нарушение которого прощалось в DOS, но карается в Windows, где освобожденную память тут же стащит другое работающее приложение. Тестеры в команде разработки Windows протестировали множество популярных приложений, чтобы убедиться, что все работает без сбоев, но SymCity зависала. Они сообщили это разработчикам Windows, которые дизассемблировали SymCity, шаг за шагом в дебаггере найдя ошибку, и добавили специальный код, проверяющий наличие SymCity в памяти и запускающий распределитель памяти в специальном режиме, в котором SymCity разрешается использовать память после ее освобождения.
И это было в порядке вещей. Команда тестировщиков Windows огромна, и она должна гарантировать – это и является ее главной задачей и ответственностью, – что каждый сможет безопасно обновить свою операционную системую. Не имеет значения, какое приложение инсталлированно, оно обязано работать, даже если ведет себя плохо, или использует недокументированные функции, или полагается на ошибочное поведение функции, которое было ошибочным в Windows n, но уже исправлено в Windows n+1. На самом деле, если вы загляните в секцию AppCompatibility вашего реестра, вы увидите целый список приложений, для которых Windows эмулирует старые ошибки и необычное поведение, поэтому они могут работать. Реймонд Чен «Меня черезвычайно бесит, когда люди обвиняют Microsoft в преднамеренной невозможности запуска приложений после обновления ОС. Если приложение не запускается под Windows 95, я воспринимаю это за персональный провал. Я трачу много бессонных ночей, фиксируя ошибки программ сторонних производителей, чтобы они продолжали работать под Windows 95.»
Много разработчиков с этим не согласно. Если приложение ведет себя неправильно, или полагается на недокументированное поведение, то оно должно перестать работать после обновления ОС. В Apple разработчики ОС всегда придерживались этой точки зрения. Поэтому так мало старых работающих программ под Macintosh. Например, много разработчиков пытались ускорить свои приложения, копируя указатели из таблицы векторов прерываний и вызывая их непосредственно, вместо использования соответствующей функции процессора. Несмотря на то, что где-то внутри «Inside Macintosh» – официальной библии Apple по программированию на Macintosh – было техническое указание «так делать нельзя», они так делали, и это работало, и их программы работали быстрее… до выхода следующей версии ОС, после они не работали вообще. Если компания вышла из бизнеса (а большинство вышло.)…что-ж, не повезло.
Для сравнения, у меня есть программа для DOS, написанная мною в 1983 году для очень оригинального IBM PC, которая до сих пор безупречно работает благодаря лагерю Реймонда Чена. Конечно, это заслуга не только Реймонда: это modus operandi ядра команды разработки Windows API. Реймонд очень точно отразил это на своем замечательном вебсайте .
Это первый лагерь. Другой лагерь назван мною лагерем журнала MSDN: по имени журнала для разработчиков, полного увлекательных статей обо всех способах отстрела собственной ноги при помощи продуктов Microsoft и собственного программного обеспечения. Лагерь журнала MSDN всегда пытается убедить вас применять новые и сложные внешние технологии, такие как COM+, MSMQ, MSDE, Microsoft Office, Internet Explorer и его компоненты, MSXML, DirectX (пожалуйста, самую последнюю версию), Windows Media Player и Sharepoint... Sharepoint! У кого он есть? Пышный наряд внешних зависимостей, каждая станет причиной сильнейшей головной боли, когда вы отправите ваше приложение заплатившему вам деньги клиенту, а оно откажется работать. Техническое имя этому – ад DLL. Это работает здесь: почему оно не работает там?
Лагерь Реймонда Чена полагает, что разработчикам будет проще, если создать условия, когда однажды написанный код запускается везде (хорошо, на любой Windows платформе). Лагерь журнала MSDN полагает, что разработчикам будет проще, если им дать мощные куски кода, которые можно использовать для достижения собственных целей, если они хотят заплатить за это головной болью от невероятно сложной установки, про огромную кривую обучения даже не упоминаю. Лагерь Реймонда Чена за консолидацию. Пожалуйста, не делайте хуже, пусть то, что уже создано, продолжает работать. Лагерю журнала MSDN нужна раскрутка новых гигантских кусков технологии, с которыми никто не сможет справиться.
А вот почему все вышесказанное имеет значение.
Microsoft утратила религию обратной совместимости
Лагерь журнала MSDN выиграл битву внутри Microsoft.
Первой большой победой стал Visual Basic.NET без обратной совместимости с VB 6.0. Без преувеличения впервые, при покупке обновления продукта Microsoft ваши старые данные (тот же код, написанный на VB6) не переносились беспрепятственно. В первый раз обновление от Microsoft не проявило уважение к плодам трудов пользователей, полученных на предыдущих версиях продуктов.
Казалось, небеса не обрушились, не внутри Microsoft. Разработчики на VB6 и так потихоньку исчезали, поскольку большинство из них были корпоративными разработчиками и мигрировали на разработку web-приложений. Настоящий долгосрочный ущерб не был виден.
Под знаменем этой победы лагерь журнала MSDN захватил власть. Внезапно изменение устоев стало нормой. IIS 6.0 вышел с другой потоковой моделью, из-за чего некоторые старые приложения не запускались. Я был шокирован, узнав, что наши клиенты с Windows Server 2003 имеют проблемы с работой FogBugz. Потом .NET 1.1 не имел идеальной обратной совместимости с 1.0. И теперь, команда разработки ОС вошла во вкус и решила вместо добавления новых функций в Windows API заменить его полностью. Нам было сказано, что вместо Win32 нужно быть готовыми к : следующему поколению Windows API. Все иначе. Основано на .NET с управляемым кодом. XAML. Avalon. Да, значительно лучше Win32, я признаю. Но не обновление – разрыв с прошлым.
Разработчики и так не были в большом восторге от сложности программирования под Windows, поэтому в массовом порядке покинули платформу Microsoft и занялись web разработкой. Пол Грэхэм – создатель Yahoo! Stores в самом начале бума доткомов – ярко : «Для начинающих компаний сейчас все больше и больше причин писать web-ориентированные приложения, потому что создание настольного программного обеспечения (desktop software) стало куда менее забавным. Если вы сегодня хотите написать настольное приложение, вы делаете это на условиях Microsoft, вызывая их API и работая с их глючной ОС. И если перед вами стоит задача написать что-то неординарное, то вы можете обнаружить, что просто проводите маркетинговое исследование для Microsoft.»
Microsoft выросла, обзаведясь большим количеством программистов, которые увлекшись доходами с обновлений, внезапно решили, что перепрограммировать все – не очень большой проект. Черт побери, мы может сделать это дважды! Старая Microsoft, Microsoft Рэймонда Чена, могла реализовать вещь наподобие Avalon – новую графическую систему – как серию DLL, которые запускаются на любой версии Windows, и могут быть включены в любое приложение. Нет технических причин так не сделать. Но Microsoft нужна причина, по которой вы купите Longhorn, все, что они добиваются это резкое изменение, сродни изменениям призошедших, когда Windows сменила DOS. Проблема в том, что Longhorn не является очень большим продвижением вперед над Windows XP; не настолько большим, как Windows над DOS. Наврядли это послужит для людей достаточным основанием для покупки новых компьютеров и программ, как когда-то они сделали из-за Windows. Хорошо, может и послужит, Microsoft это, несомненно, необходимо, но то, что я сейчас наблюдаю, не очень убедительно. Microsoft сделало много неправильных ставок. , WinFS, рекламируемое как средство организации поиска путем представления файловой системы в виде реляционной базы данных, игнорирует тот факт, что настоящее средство для поиска это выполнение поиска. Не заставляйте меня впечатывать во все мои файлы метаданные, которые я могу искать, использую язык запросов. Просто сделайте мне одолжение и поищите впечатанную мною строку на чертовом жестком диске, быстро, используя полнотекстовые индексы и другие технологии, наскучившие еще в 1973.
Автоматическая коробка передач одерживает победу
Поймите меня правильно… Я считаю .NET великой средой разработки, а Avalon с XAML – гигантский прогресс над старыми способами написания графических приложений для Windows. Наибольшее преимущество .NET заключается в автоматическом управлении памятью.
В начале девяностых многие из нас полагали, что главная битва произойдет между процедурным и объектно-ориентированным стилем программирования, и воспринимали объектно-ориентированное программирование как средство резкого повышения продуктивности программистов. Я тоже так думал. Некоторые до сих пор так думают. Получается, мы ошибались. Объектно-ориентированное программирование прикольная штука, но не повышает продуктивность, как это обещалось. Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде. Всякий раз, когда вы слышите чье-то хвастовство о том, насколько продуктивен их язык, вероятно, большую часть продуктивности они достигают за счет автоматического управления памятью, даже если не признаются в этом.
Врезка
Почему автоматическое управление памятью значительно улучшает вашу продуктивность? 1) Потому что вы можете написать f(g(x)) не беспокоясь о том, как освободить память, занятую возвращаемым значением функции g, значит вы можете использовать функции, которые возвращают интересные сложные типы данных и функции, трансформирующие интересные сложные типы данных, что в результате позволяет вам работать на более высоком уровне абстракции. 2) Потому что вам не надо тратить время на код, освобождающий память или отслеживать утечки памяти. 3) Потому что вам не надо аккуратно координировать точки выхода из ваших функций, чтобы убедиться, что память освобождена должным образом.
Ревностные поклонники гоночных машин, вероятно, пошлют мне письма ненависти, но мой опыт показывает, что есть только один случай, при нормальном вождении, когда хорошая автоматическая коробка передач хуже ручной. Также и в разработке программного обеспечения: почти везде автоматическое управление памятью лучше ручного и куда продуктивнее.
Если вы занимались разработкой настольных приложений в ранних версиях Windows, то Microsoft предлагал вам два пути: написать код на С, напрямую вызывающий Windows API, и самостоятельно управлять вашей памятью, или использовать Visual Basic, который будет управлять памятью за вас. Эти две среды разработки я использую чаще всего последние лет тринадцать, я знаю их вдоль и поперек, и мой опыт показывает значительно большую продуктивность Visual Basic. Часто я писал один и тот же код, на С++, вызывая Windows API, и на Visual Basic. На С++ всегда требовалось в три-четыре раза больше работы. Почему? Управление памятью. Самый легкий путь понять почему – взглянуть на документацию к любой функции Windows API, возвращающую строку. Посмотрите внимательно как много дискуссий о том, кто должен выделить память под эту строку, и как вам договариваться о размере выделяемой памяти. Обычно, вы вызываете функцию дважды, в первый раз вы сообщаете, что выделили ноль байт, и она возвращает вам ошибку «недостаточно выделенной памяти», а также говорит, сколько памяти вам необходимо выделить. Это в том случае, если вам повезло, и не надо не вызывать функцию, возвращающую список строк или даже структуру переменной длины. В любом случае, простая операция открытия файла, записи строки и его закрытия займет страницу кода, если используется чистый Windows API. На Visual Basic подобная операция займет три строки.
Итак, у нас два мира программирования. Большинство решило, что мир управляемого кода лучше мира кода неуправляемого. Visual Basic был (и вероятно остается) первым из числа самых продаваемых языков программирования всех времен; для разработки под Windows программисты отдают предпочтение ему, а не С или С++, не смотря на то что, крутые программисты избегали его, так как в названии присутствует слово «Basic» (элементарный), хотя это был весьма современный язык с чертами объектно-ориентированности, с очень малым количеством оставшейся грязи (номера строк и оператор LET исчезли как утренний туман). Еще одна проблема заключалась в необходимости снабжать программу специальной VB-библиотекой, что имело значение при передаче программ по модему, но хуже того, позволяло другим программистам увидеть, что ваше приложение было разработано (какой стыд!) на Visual Basic.
Одна библиотека для всего
И вот пришел .NET. Это был великий проект, супер-пупер унифицирующий проект, призванный расчистить эту кашу раз и навсегда. Конечно, с управлением памятью. Останется и Visual Basic, но он заполучит новый язык, по духу фактически тот же Visual Basic, но с новым С-подобным синтаксисом фигурных скобок и точек с запятой. Самое главное, новый гибрид Visual Basic и С будет называться Visual C#, так что вам больше не придется говорить, что вы программируете на Бейсике. Все эти ужасные Windows функции, ошибки обратной совместимости, и семантика возврата строк будут выброшены и заменены единым объектно-ориентированным интерфейсом только с одним видом строк. Одна библиотека для управления всем. Это было прекрасно. И технически они этого добились. .NET – великая среда разработки, управляющая вашей памятью, с богатым, полным и непротиворечивым интерфейсом с операционной системой и богатой, суперполной и элегантной объектной библиотекой базовых операций.
Ну а пока люди мало используют .NET.
О да, некоторые используют.
Но идея унификации мешанины из программирования на Visual Basic и Windows API созданием полностью новой среды программирования не с одним, не двумя, а с тремя языками (или есть четвертый?) похожа на попытку заставить замолчать ссорящихся детей еще более громким криком «Замолчите!». Это сработает только в сериале. В реальной жизни, когда вы кричите «Замолчите!» двум громко спорящим людям, вы просто становитесь третьей стороной в споре.
(Между прочим, то же самое происходит с форматом RSS. Он разделился на несколько версий с неточными спецификациями и большим количеством политической борьбы, а попытка навести порядок созданием еще одного формата, названного Atom, привела к нескольким различным версиям RSS плюс одна версия Atom, неточным спецификациям и большим количеством политической борьбы. Когда вы пытаетесь объединить две противостоящие силы созданием третьей альтернативы, вы получите три противостоящие силы. Вы ничего реально не объединили и не исправили.)
В итоге, вместо унификации и упрощения, мы имеем большую шестистороннюю путаницу, где каждый пытается вычислить, какой стратегии разработки придерживаться, и можно ли себе позволить портировать существующие приложения под .NET.
Не имеет значения насколько Microsoft последовательна в своем рекламном слогане («просто используйте .NET – доверьтесь нам!»), большинство ее покупателей до сих пор используют C, C++, Visual Basic 6.0 и классический ASP, не говоря об инструментарии других компаний. А те, кто используют .NET, используют ASP.NET для разработки веб-приложений, которые работают на Windows Server и не нуждаются в Windows клиентах, что является ключевой точкой, о которой я расскажу больше, когда буду рассказывать о Веб.
Ой, подождите, будет еще больше!
Сейчас в Microsoft много разработчиков фантазируют о том, что недостаточно переписать весь Windows API: они должны переписать его дважды. На конференции прошлого года они проанонсировали следующую версию своей операционной системы под названием Longhorn, помимо всего прочего в нее будет включен полностью новый API графического интерфейса пользователя – кодовое имя Avalon – написанный с нуля, чтобы использовать все преимущества современных графических адаптеров и 3D графики реального времени. И если вы сегодня при разработке графических приложений под Windows используете «официальную» свежайшую и величайшую библиотеку WinForms от Microsoft, то через два года для обеспечения совместимости с Longhorn and Avalon вам придется начать заново. Что и объясняет, почему WinForms полностью мертворожденный проект. Надеюсь, вы не потратили на него много денег. Джон Уделл нашел плакат от Microsoft, озаглавленный «Как мне выбрать между WinForms и Avalon?», и : «почему я должен выбирать между WinForms и Avalon?». Хороший вопрос, на который он не находит хорошего ответа.
Итак, у вас есть Windows API, у вас есть VB, и теперь вы получили .NET с букетом из нескольких языков, и вы ни к чему особо не расположены, потому что, мы делаем Avalon, который будет работать только на новейшей операционной системе от Microsoft, а ее дооооолго ни у кого не будет. Лично у меня до сих пор не нашлось времени для глубокого изучения .NET, и мы до сих пор не портировали два проекта нашей компании Fog Creek с классического ASP и Visual Basic 6.0 на .NET, так как для нас нет прибыли от инвестиций. Нету. Это просто : Microsoft понравится, если я перестану добавлять новые возможности в нашу систему по отслеживанию ошибок в программном обеспечении и в систему управления контентом, а вместо этого потрачу несколько месяцев, портируя их в другую среду разработки, что не принесет пользы ни одному клиенту, а следовательно не даст ни одной дополнительной продажи, а следовательно это пустая трата нескольких месяцев, что прекрасно для Microsoft, имеющей собственную систему управления контентом и отслеживания ошибок в программном обеспечении, так что для них нет ничего лучшего, если я потрачу время на переход, а потом потрачу год, а то и два, на переход на Avalon, в то время как они функционально улучшают свое, конкурирующее нам, программное обеспечение. Праааавильно.
Ни у одного программиста со сдельной оплатой не найдется времени на изучение всех этих год, а то и два на переход на Фмфдщт стая новых инструментов разработки из Рэдмонта, только потому, что в Microsoft слишком много дурных служащих, занимающихся разработкой инструментов программирования!
Сейчас не 1990
Microsoft созрела в восьмидесятые и девяностые во времена резкого роста числа персоналок, когда количество проданных компьютеров в течении года превышало количество уже установленных. Это означало, что если вы сделали продукт, который работает только на новых машинах, то в течение года или двух он мог завоевать весь мир, даже если никто на него не перешел с другого продукта. Это одна из причин, по которой Word и Excel заменили WordPerfect и Lotus так быстро: Microsoft просто ждала следующей большой волны апгрейдов и продавала Windows, Word и Excel корпоративным пользователям, покупающих следующую смену своих компьютеров (в некоторых случаях первую). Во многих отношениях Microsoft не было нужды учиться переводу парка компьютерной техники с продукта N на продукт N+1. При покупке компьютеров люди рады приобрести последние новинки от Microsoft, но менее вероятно, что они захотят приобретать обновления. Это не имело значения, когда компьютерная индустрия росла со скоростью степного пожара, но теперь, когда мир насыщен персоналками, большинство из которых «просто замечательны, спасибо», Microsoft внезапно понимает, что выпуск новой версии занимает намного больше времени. Когда они попытались устроить «Конец жизни» Windows 98, то выявилось столько много использующих ее людей, что ей продлить поддержку старой скрипучей бабушки на еще несколько лет.
К сожалению, эти новые бравые стратегии, вещи наподобие .NET, Longhorn и Avalon, рождающие новый API, к которому будут привязаны люди, не будут работать, если большинство продолжает использовать вполне удовлетворительные компьютеры 1998 года рождения. Даже если Longhorn и выйдет в 2006 году, во что я абсолютно не верю, пройдет пару лет, прежде чем он достаточно распространится, и будет восприниматься как платформа для разработки. Разработчики, разработчики, разработчики и разработчики не покупаются на многочисленные разобщенные предложения от Microsoft, как нам следует разрабатывать программы.
Наступление Web
Дальнейший рассказ невозможен без упоминания Web. У каждого разработчика есть выбор при планировании нового приложения: он может построить его для Web, или создать «богатого (толстого) клиента», запускающегося на персоналке. «За» и «против» просты: веб-приложения проще распространять, а «богатые клиенты» предлагают быстрое время отклика, что делает возможным более интересные интерфейсы пользователя.
Веб-приложения проще распространять по причине отсутствия процесса инсталляции. Инсталляция веб-приложения означает набор URL в адресной строке. Сегодня я инсталлировал новое приложение Google, набрав Alt+D, gmail, Ctr+Enter. Намного меньше проблем совместимости. Все пользователи вашего продукта работают на одинаковой версии, нет необходимости поддерживать набор старых версий. Вы можете использовать любую программную среду, какую захотите, вам только нужно заставить работать это на своем сервере. Ваше приложение автоматически доступно для практически каждого компьютера на планете.
Но платой за это станет гладкость пользовательского интерфейса. Вот несколько примеров того, что вы не можете действительно хорошо делать в веб-приложении:
1. Создавать программы с быстрой графикой.
2. Строить систему проверки орфографии в режиме реального времени с красными волнистыми подчеркиваниями.
3. Предупреждать пользователей, что они потеряют свои данные, если нажмут кнопку закрытия браузера.
4. Обновлять на основе изменений пользователя небольшую часть экрана без обращения к сервера.
5. Создавать быстрый клавиатурный интерфейс (без необходимости использовать мышь).
6. Позволять людям продолжать работу, когда они не подсоединены к Интернет.
Не все из вышеперечисленного представляет собой большую проблему. Вскоре часть проблем будет разрешена остроумными программистами на Javascript. Два новых почтовых веб-приложения и показывают хорошую работу по преодолению или полному разрешению некоторых вышеназванных пунктов. А пользователей, похоже, не заботят небольшие затруднения и «тормознутость» веб-интерфейса. Почти все мои знакомые, по тем или иным причинам, совершенно счастливы от веб-интерфейса электронной почты, несмотря на все мои убеждения в том, что «богатый клиент», э-э, богаче.
Итак, веб-интерфейс пользователя решает 80% всех проблем, и даже без нового браузера мы, вероятно, достигнем процентов 95. Это терпимый уровень для большинства людей, и, несомненно, для разработчиков, которые голосуют за веб-разработку практически при каждом значимом проекте.
Это значит, что, внезапно, API от Microsoft уже не так важен. Веб-приложениям не нужен Windows.
Это не значит, что в Microsoft ничего не заметили. Конечно, заметили, а когда последствия стали ясны, ударили по тормозам. Такие новые многообещающие технологии, как и DHTML были остановлены в своем развитии. Команда разработки Internet Explorer похоже исчезла; результатов их деятельности не видно уже несколько лет. Ни в коем случае в Microsoft не позволят DHTML стать чуточку лучше: это слишком опасно для их ключевого бизнеса – «богатых клиентов». Сегодня Microsoft делает ставку на «богатого клиента». Вы увидите это в каждом слайде презентации Longhorn.
Проблема в следующем: слишком поздно.
Мне немного жаль
Мне действительно немного жаль. По мне, Веб – это классно, но веб-ориентированные приложения с их гадким, непоследовательным интерфейсом с большим временем реакции – большой шаг назад в отношении удобства и практичности (usability) интерфейсов. Я люблю «богатых клиентов» и сойду с ума, если придется работать на веб-версиях ежедневно мною используемых программ: Visual Studio, CityDesk, Outlook, Corel PhotoPaint, QuickBooks. Но это то, чем собираются нас снабдить разработчики. Больше никто (в смысле «меньше чем 10 000 000 человек») не хочет работать с Windows API. Венчурный капитал не будет инвестировать в разработку Windows-приложений, так как боится конкуренции с Microsoft. И, пожалуй, большинство пользователей не волнует паршивый веб-интерфейс также, как волнует меня.
А вот решающий довод: я заметил (и друг из агентства по найму подтвердил), что программист на Windows API здесь в Нью-Йорке, знающий С++ и СОМ, зарабатывает около 130 000$ в год, тогда как типичный веб-программист, использующий язык с автоматическим управлением памятью (Java, PHP, Perl, даже ASP.NET) зарабатывает около 80 000$ в год. Это огромная разница, и когда я поговорил с друзьями из Microsoft, они признали, что их фирма потеряла целое поколение разработчиков. Причина, по которой платят 130 000 $ программисту со знанием СОМ, заключается в том, что никто за последние восемь лет не утруждал себя изучением СОМ, так что вам необходимо найти действительно опытного и зрелого человека, обычно уже в менеджменте, и убедить его работать программистом, связаться (боже, помоги мне!) с маршаллингом, моникерами, распределенными потоками, агрегатами и миллионом других вещей, которые понимал только Дон Бокс, и даже Дон Бокс больше .
Как бы мне не было противно, большое количество программистов давно ушли в веб и отказываются возвращаться. Большинство разработчиков под .NET – ASP.NET разработчики, программирующие для Microsoft веб-сервера. ASP.NET великолепен; я занимаюсь веб-разработкой десять лет, и это действительно на целое поколение опережает все остальное. Но это серверная технология, так что клиенты могут использовать любую платформу. И это прекрасно работает под Linux при помощи .
Ни одно из этих предсказаний не предвещает ничего хорошего Microsoft и доходам, получаемых благодаря власти API. Новый API это HTML, и победителями на рынке разработки приложений станут люди, которые смогут заставить HTML петь.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Как сделать так, чтобы ваше резюме прочитали
Автор: Джоэл Сполски
Переводчик: Анар Мустафаев
Редактор: Андрей Попов
26 января 2004
Мне приходится перелопачивать большую кучу заявок на работу в Fog Creek Software на время летней стажировки, и, я даже не знаю как это сказать, но некоторые из них очень, очень плохи. Это не говорит о том что претенденты тупы или необразованны, хотя может быть это и так. Я не собираюсь до этого докапываться, потому что у меня масса прекрасных резюме на два вакантных места, и мне нет нужды тратить время на интервьюирование людей которые даже не потрудились правильно написать название моей компании.
Поэтому вот несколько советов для критического просмотра, если вы посылаете резюме:
Резюме – это способ перейти на следующую стадию: интервью. Компании обычно получают дюжины резюме на каждую вакансию… мы получаем от 100 до 200 на каждую вакансию. Невозможно провести интервью с таким количеством людей. Единственная надежда - это отсеять кандидатов по их резюме. Не думайте о резюме как о способе получить работу: думайте о нем как о способе внушить нанимающему менеджеру некоторое сожаление если он всё же нажимает клавишу DELETE. Как минимум технически, ваше резюме должно быть идеально подготовлено к выживанию.
Если у вас нет соответствующей квалификации, не пытайтесь получить эту работу. Когда в перечне работ вы видите «летняя стажировка», не спрашивайте о полной занятости. Вы ее не получите, вы только потеряете свое время. (Конечно, это не относится к будущему, потому что ваша заявка была удалена так быстро, что я вас и не вспомню когда у нас будет вакансия на полную занятость и вы попытаетесь ее получить.)
А вот это действительно меня достает. Выучите взаимоотношения пробелов с другими знаками препинания. Внимание всему населению Индии: где бы ни была запятая, всегда ставится один пробел и всегда после запятой, и никак не перед ней. Спасибо.
Раньше резюме посылались обычной почтой и включали в себя титульный лист на котором объяснялось почему резюме было послано. Сейчас, так как мы используем электронную почту, нет какой бы то ни было причины присоединять сопроводительное письмо к электронному сообщению в виду дополнительного файла, а затем писать «сопроводительное сопроводительного» письмо в теле самого сообщения. Это просто бессмысленно.
Еще бывает, что какой-нибудь тупица присылает два больших Word документа без какого-либо текста в теле e-mail. На таких письмах срабатывает спам-фильтр. Я их даже НЕ ВИЖУ.
Пожалуйста, не используйте сопроводительные письма, которые вы скопировали из книг. Если вы пишите: «Я понимаю, что от кандидата требуется умение работать в команде, разбираться в деталях, хорошо работать в жестких условиях, умение находить общий язык с людьми из других отделов фирмы», - тогда, в лучшем случае, люди подумают что вы какой-то дурацкий артист, а в худшем, они будут думать, что вы родились без той части мозга которая отвечает за формирование ваших собственных мыслей и идей.
Местоимение «я» (в английском языке) всегда пишется с большой буквы. Все предложения всегда заканчиваются точкой. Если ваша титульная страница выглядит подобно этой, то я даже не взгляну на ваше резюме:
i m interested in your summer job.
here is my resume
--------------------------------------------------------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
И пока я здесь, я хотел бы сказать, что анонимные почтовые ящики и почтовые ящики AOL не посылают хороших писем. Они не дисквалифицируют вас немедленно, так как много людей ими пользуются, но crazydood2004 на hotmail.com действительно не впечатлит меня так, как имя на alumni.something.edu. Вам действительно нужно знать Yahoo! ли я? Вы действительно хотите рекламировать Yahoo! SiteBuilder – конкурент одного из продуктов Fog Creek, и вы действительно хотите получить работу в FogCreek?
В англоязычном мире обращение к мистеру Джоелу Спольски (Mr. Joel Spolsky) «Dear Spolsky» не обоснованно. Можно написать «Dear Mr. Spolsky» или «Dear sir», или, возможно «Hi Joel!». Но «Dear Spolsky» обычно следует за историей о проматывании денежных фондов и необходимости занятия моего банковского счета.
Не говорите мне об одном из требований вакансии, а потом о том что вы не хотите следовать ему. «Одно из требований для Летней Стажировки гласит, что вы должны персонально пройти интервью в Нью-Йорке. Меня интересует эта работа, но я нахожусь в Восточном Нигде, ТН.» Хорошо, это замечательно, достопочтенный, оставайтесь там. Другое требование, которое мы написали в требованиях «Отличное владение письменным и разговорным английским.» О да, несомненно, это было наше первое требование. Поэтому окажите себе услугу, и найдите кого-нибудь кто бы проверил ваше сопроводительное письмо на явные ошибки. Как я говорил раньше, не давайте мне повод выбросить ваше резюме в мусорную корзину.
Я не знаю, почему мне нужно все это растолковывать, ведь все это есть в каждой книге на тему «как рассылать резюме», вот здесь в главе 1, тем не менее я продолжаю получать много резюме которые показывают чрезвычайную нехватку понимания того, что нужно чтобы быть приглашенным на интервью.
Позвольте мне все же быть не столь негативным, и дать несколько конструктивных советов.
Прочитайте все несколько сот раз и дайте кому-нибудь прочитать. Тому у которого хорошие знания по языку.
Напишите ваше собственное сопроводительное письмо, которое предназначена специально для той работы, на которую вы претендуете.
Изучите способы, которыми предлагается посылать резюме. Они пишутся не просто так. Например инструкции на нашем веб сайте советуют вам посылать резюме на jobs@fogcreek.com. Далее резюме записывается в папку которую мы просматриваем для поиска подходящих кандидатов. Если вы думаете по какой-то причине, что ваше резюме обратит на себя больше внимания, если вы напечатаете его и пошлете почтой, что вы как-то «выделитесь», выбросьте это из головы. Резюме на бумаге не может попасть в папку для электронных писем, пока мы не отсканируем его, и вы знаете что? В моем офисе сканер стоит сразу после шредера, а шредером пользоваться легче.
Не подавайте заявление о приеме на работу в слишком большое количество мест. Не думаю, что следует обращаться в более чем три или четыре места за раз. Резюмеспам (в оригинале: Resumespam) или любое указание на то, что вы претендуете на 100 рабочих мест, выставляет вас отчаявшимся, что в свою очередь показывает вас неподготовленным. Вам нужно выглядеть так, чтобы было видно, что вы достаточно хорошо отвечаете жестким требованиям. Вы должны решить, где вы хотите работать, потому что вы достаточно умны для того, чтобы выбирать, поэтому вам нужно только подать заявку на одно или два рабочих места. Ваше собственное сопроводительное письмо показывает, что вам известно, чем занимается компания и вы достаточно внимательны, чтобы заслужить шанс работать в ней.
Кое что из этого может звучать достаточно тривиально. В действительности, когда мы просматриваем резюме, мы ищем кого-то, кто страстно и успешно делает то, что он пытается делать. Нам нравятся те, страсть которых программное обеспечение. Написание условно-бесплатных (shareware) программ пока вы тинэйджер - это такая же хорошая квалификация для нас, как поступление в МТИ (Массачусетский технологический институт (MIT - Massachussets Institute of Technlogies)). Это ваша история жизни, и ко времени, когда вы подаете заявление на работу, может быть, слишком поздно это менять.
Откажусь ли я от тех, кто не совсем понимает взаимосвязь между запятой и пробелом? Ну, не обязательно. Но когда у меня на два места летней стажировки 300 заявок, то вот что я делаю с резюме: я делю их на три кучи: Хорошие, Удовлетворительные и Плохие. Я даю те же резюме Майклу, и он делает с ними ту же вещь. Всегда есть достаточно претендентов, которых мы оба складываем в Хорошую кучу, и только у этих людей действительно остается шанс. В принципе, если нам не достаточно людей, которых мы оба отнесли к «хорошим» мы могли бы рассматривать тех, кто Хорошие/Удовлетворительные, но практически, этого никогда не случалось. Я бы очень хотел взвешивать каждого по его заслугам вместо поверхностной оценки по резюме, но это просто не реально, и нет причины, почему бы образование в колледже не давало бы вам такое право.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Лорд Палмерстон в программировании
Автор: Джоэл Сполски
Переводчик: Федор Иркашов
Декабрь 11, 2002
Были времена, когда если вы прочли Питера Нортона, вы знали все, что можно было знать о программировании IBM-PC. За последние 20 лет программисты во всем мире много проработали, выстраивая обобщение над обобщением на IBM-PC, что бы сделать программирование легким и более мощным.
Но закон гласит, что даже если они строят обобщения позволяющие сделать программирование проще, количество вещей которые вы должны знать, что бы быть отличным программистом все время возрастает.
Стать профессионалом, действительно профессионалом только в одной области программирования занимает годы. Конечно, множество ярких тинэйджеров выучивают Delphi за одну неделю и Python за другую и Perl за третью и думают что они профессионалы. Они так еще и не поняли, как много они пропустили.
Я проработал с ASP и VBScript, с тех пор как они только появились. VBScript изящнейший язык на земле и ASP программирование состоит в изучении пяти классов, только два из которых используются достаточно часто. И только сейчас наконец я по видимому знаю лучший способ построения ASP/VBScript приложений. Я думаю, что узнал, наконец, где лучшее место размещения кода для доступа к базе данных, лучший способ использования ADO для получения наборов данных, лучший способ разделить HTML и код и так далее. И я в довершение всего использую регулярные выражения вместо специальных на каждый случай функций работы со строками. Только на последней неделе я научился выгружать COM объекты из памяти, для того чтобы перекомпилировать их (без перезапуска всего COM сервера).
Fog Creek слишком мала что бы иметь узких специалистов, таким образом когда мне понадобилось написать по настоящему хороший инсталлятор для , нашего основанного ASP/VBScript продукта, мне понадобилось несколько лет опыта в C++/MFC и годы опыта с различными Windows API, а также хорошие навыки работы с Corel PhotoPaint для того чтобы нарисовать подходящую картинку в углу диалогового окна мастера. Тогда для того чтобы FogBUGZ отлично работал с Unicode, мне понадобилось написать маленький ActiveX элемент управления с использованием C++ и ATL, для чего понадобились годы опытов в С++ и COM и неделя или около того обучения кодировкам символов в то время, как я реализовывал этот код для CityDesk.
Таким образом, когда мне встретилась непонятная ошибка, проявлявшаяся только в Windows NT 4.0, мне понадобилось только 3 минуты отладки, потому что я знал, как использовать VMWare, и у меня была чистая предустановленная NT 4.0 для VMWare, также я знал, как выполнять удаленную отладку в Visual C++ и я знал, что надо заглянуть в EAX регистр для получения, возвращаемого функцией значения. Тому, кому это все в новинку понадобилось бы час или более что бы отладить ту же самую проблему, а я уже знал огромное количество “штучек” которым я учился, по существу, с 1982 года когда я получил мой первый IBM-PC и ту самую книгу Питера Нортона.
Неудержимые абстракции ведут к тому, что мы живем с очень резкой кривой обучения: вы можете выучить 90% того, что вы используете каждый день за неделю обучения. Но что бы разобраться в остальных 10% займет еще пару лет. Это то, чем по настоящему опытные программисты отличаются от людей, которые говорят ”не важно, что вы хотите, что бы я сделал, я могу открыть книгу и научиться делать это”. Если вы строите команду, это нормально иметь множество менее опытных программистов для написания больших участков кода с использованием обобщенных инструментов, но команда не может начать работать, если у вас нет нескольких по настоящему опытных членов команды для выполнения действительно сложной работы.
Существует множество областей программирования, каждая из которых требует огромного количества знаний для настоящего профессионализма. Здесь три из них которые я сам знаю лучше всего:
MFC/C++/Windows
VBScript/ASP
Visual Basic
Все, по существу, что вы могли бы назвать Windows программированием. Да, я писал Unix код и Java код, но не очень много. Моя квалификация в Windows программировании проистекает оттого, что я знаю не только базовые технологии, но и всю поддерживающую инфраструктуру. Таким образом, я утверждаю, что я действительно хорош в Windows программировании, потому что я также знаю COM, ATL, C++, 80x86 Ассемблер, различные Windows API, IDispatch (OLE Automation), HTML, DOM, объектную модель Internet Explorer, внутренности Windows NT and Windows 95, LAN Manager и сетевую работу в NT, включая безопасность (ACEs, ACLs, и все остальные вещи), SQL и SQL Сервер, Jet и Access, JavaScript, XML, и несколько других о площади гипотенузы. Когда я не смог добиться от StrConv функции того чего я хотел, я сварганил элемент управления COM что бы попасть в C++ с помощью ATL и вызвать MLang функции, что бы не оказаться побежденным. Мне понадобились годы, что бы достичь этого.
Существует множество других областей программирования. Скажем люди, разрабатывающие для BEA Weblogic, которые знают J2EE, Oracle и всевозможные Java штучки, о которых я не знаю достаточно даже для того чтобы их перечислить. Или твердое ядро разработчиков для Macintosh, которые знают CodeWarrior, MPW, Toolbox программирование in System 6 через X, Cocoa, Carbon, и даже такие такую милую устаревшую вещь как OpenDoc, которая не может больше помочь.
Очень не много людей имеют достаточно знаний более чем в одной или двух областях, потому что там так много всего нужно узнать, даже что если вы проработали в одной из этих областей пару лет, вы все равно не разобрались во всем.
Но учиться вы должны.
Люди отчасти , когда они приходят на собеседование и получают отказ, потому что они не имеют опыта в Win32 (или в J2EE, или в Mac программировании, или чем-нибудь еще). Или они раздражаются, потому что идиоты рекрутеры, которые не узнали бы MSMQ даже если бы он пинал их под зад, звонят им и спрашивают “Имеют ли они 5 лет опыта в MSMQ ”.
До тех пор пока вы не посвятите Windows программированию множество времени, вы можете думать, что Win32 это всего-навсего библиотека, похожая на многие другие библиотеки, вы прочитаете книжку, выучите ее и будете вызывать, когда она вам понадобится. Вы можете думать, что основу программирования составляют ваши превосходные C++ знания 90%, а различные API это только 10%-ый пушок, в котором вы сможете разобраться за несколько недель. Этим людям я скромно подсказываю: времена изменились. Соотношение изменилось на противоположное.
Очень немного людей работает над низкоуровневыми C алгоритмами, которые только перемещают байты и не более того. Большинство из нас проводит все наше время эти дни, вызывая различные API, а, вовсе не перемещая байты. Каким бы превосходным C++ кодировщиком ни был человек без опыта в API, он знает только около 10% того, что он должен использовать каждый день для написания кода запускаемого на API. Когда дела в экономике , это не имеет значения. Вы все еще имеете работу и наниматели платят стоимость вашего обучения соответствующей платформе. Но когда в и 600 человек подают заявления на каждую открытую вакансию, наниматели могут позволить себе удовольствие выбирать программистов которые уже эксперты в интересующей их области. Например, программистов, которые могут назвать четыре пути заслать файл по FPT из кода на Visual Basic и слабые и сильные стороны каждого из них.
Огромные пространства всех этих областей ведут к бесцельным зажигательным войнам (flame wars) чей мир лучше. Вот такой самодовольный комментарий сделал кто-то анонимно на моей доске обсуждений:
“Еще одна причина почему мне нравится жить в ‘свободном мире’. Свобода слова (практически полная) и свобода от засилья таких вещей как установочные программы и реестр – я упомянул лишь немногие из них.”
Я думаю этот человек хотел сказать, что в Linux он не должен писать установочные программы. Ну, ненавижу разочаровывать вас, но вы имеете кое-что гораздо более осложненное: imake, make, config files и все эти штуки, и когда вы заканчиваете, вы должны распространять приложения с 20Kb INSTALL файлами полных остроумных инструкций типа “Вам понадобится zlib” (что это?) или “Это может занять некоторое время. Идите возьмите каких-нибудь сморчков(runts)” (сморчки это тип конфет, я думаю). И реестр — вместо одного большого улья (hive) имя/значение пар, вы имеете тысячи разных файловых форматов, по одному на приложение, .whateverrc и foo.conf расплодившимися повсюду. Emacs принуждает вас изучать, как программировать на Лиспе, если вы захотите изменить настройки, также каждая оболочка (shell) принуждает вас изучать ее персональный диалект shell script программирования если вы захотите изменить настройки и так далее, и так далее.
Люди который знают только одну область программирования становятся действительно ограниченными и всякий раз когда они слышат о осложнениях в других областях, это заставляет их думать что их область не имеет осложнений. Но они есть. Вы минуете их потому, что умеете это делать. Эти области очень большие и сложные в сравнении с чем бы то ни было. Лорд Палмерстон: “Шлезвиг-Гольштейн вопрос настолько осложнен, что только три человека в Европе вообще понимают его. Один был Принц Альберт, который умер. Второй был немецкий профессор, который сошел с ума. Я третий и я уже забыл все, что знал о нем”. Различные области программного обеспечения настолько огромны и имеют настолько много аспектов, что когда я вижу других умных людей пишущих сообщения об ошибках (blog entry) говорящие что-то , например “Microsoft это плохая операционная система”, откровенно говоря, это выглядит глупо. Вообразите попытку охватить миллионы строк кода с сотнями основных областей созданных тысячами программистов за одно или два десятилетия, тогда как нет ни одного человека, который мог бы разобраться даже в большей части этого. Я также не защищаю Microsoft, я только говорю что слишком большие обобщения сделанные с позиции большого невежества это одна из самых больших потерь времени в сети сегодня.
Постоянные читатели, к этому времени заметили, что я думал о проблеме возможности выпуска приложений для Linux, Macintosh, и Windows без необходимости несоразмерно платить за Linux и Macintosh версии. Для этого вам нужна какая-нибудь кросс - платформенная библиотека.
Java была такой, но Sun не понимала пользовательский интерфейс настолько хорошо, что бы выпустить действительно гладкие естественно ощущающиеся приложения. Подобно тому как из Звездного пути смотрящие на землю через телескопы, они знали точно на что человеческая еда должно быть похожа, но они не понимали что она должна иметь вкус как у человеческой еды. E У Java приложений меню расположены в правильном месте, но они работают совсем не так, как в других Windows приложениях. А их диалоги с закладками выглядят довольно страшно. И нет пути, не важно как усердно ты трудишься, сделать их меню выглядящим точно как Excel меню. Почему? Потому что Java не дает тебе достаточно хорошего пути обратится к родным возможностям платформы, так как это сломало бы обобщение. Когда вы программируете в AWT вы не можете выяснить HWND окна, вы не можете вызвать ни один из Microsoft API и вы естественно не можете перехватить WM_PAINT и обработать его по-своему. И Sun сделал это достаточно ясно, если вы попытаетесь сделать это то, не будете Чисты. Вы будете Испачканы, и черт с вами.
После нескольких хорошо освещенных провалов построить пользовательский интерфейс с использованием Java (т.е. Corel's Java Office suite и Netscape's Javagator), достаточно много людей решили держатся подальше от этой области. построил оконную библиотеку с самого основания используя только родные элемент управления, таким образом они могли писать Java код и при этом иметь приемлемый вид окон и ощущения от работы с ними.
Mozilla инженеры решили разрешить с помощью своего собственного изобретения названного XUL. До сих пор я впечатлен. Mozilla, наконец, добралась до момента, где она на вкус как настоящая еда. Даже мое любимое пугало Alt+Space N для минимизации окна работает в Mozilla. Это заняло у них достаточно много времени, но они сделали это.
Mitch Kapor, который основал Lotus и создал 123, в своем следующем приложении использовать нечто называемое wxWindows и wxPython для кросс платформенной поддержки.
Что лучше XUL, Eclipse's SWT, или wxWindows? Я не знаю. Все они настолько большие области, что я не могу по настоящему попробовать их и сказать. Не достаточно просто прочитать описание. Вы должны кровью и потом проработать с этими приложением год или два, перед тем как вы узнаете, что оно достаточно хорошо, либо поймете, что не имеет значения все ваши старания, вы не сможете придать вашему графическому интерфейсу вкус настоящей еды. К несчастью, для большинства проектов вы должны решить, какую область программирования вы будете использовать, перед тем как напишите первую строчку кода, а это уж точно момент, когда вы имеете меньше всего информации. В нашей предыдущей работе у нас была довольно плохая архитектура, потому что первые программисты учились программированию C++ и программированию под Windows в процессе работы над проектом. Старейший код был написан без всякого представления об управляемом событиями программировании. Базовый класс для представления строк (конечно, мы имели свой собственный класс) был взят из книжного примера и содержал все ошибки, которые вы можете сделать, проектируя C++ класс. В конце концов, мы вычистили и переработали множество этого старого кода, но он доставал нас время от времени.
Таким образом, теперь, мой совет следующий. Не начинайте нового проекта без как минимум одного архитектора программного обеспечения с несколькими годами реального опыта в языке, классах, различных API и платформах под которые вы строите приложение. Если у вас есть выбор платформ, используйте ту в написании кода, для которой ваша команда имеет больше опыта, даже если она и не самая модная и номинально не самая продуктивная. А когда вы разрабатываете обобщающие или программные инструменты уделите больше внимания проверке слабых мест.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Мастерство
Автор: Джоэл Сполски
Переводчик: Станислав Миронов
1 декабря 2003
Создание ПО -- это не промышленное производство. В 1980-х годах все были запуганы тем, что японские компании, выпускающие ПО, создавали "фабрики программ", которые должны были выдавать высококачественный код на сборочном конвейере.Это ничего не значило тогда, не значит и сейчас. Заталкивание большого количества программистов в одно помещение и выстраивание их в аккуратные ряды не особо помогло в борьбе с количеством ошибок.
Если написание кода это не конвейерное производство, то что это? Некоторые предлагают термин мастерство. И это не совсем так, потому что мне не важно, что вы скажете, но: то диалоговое окно в Windows, которое спрашивает как вы хотите проиндексировать файл справки никаким образом, формой или видом не напоминает то, что нормальный человек воспринимает под словом "мастерство".
Я бы хотел рассказать вам об одном куске кода, который я переписывал для CityDesk 3.0: код импорта файлов. (Реклама: -- это лёгкая в использовании система управления публикациями производства моей компании.)
Описание кажется таким же простым как и любая часть программы. Пользователь выбирает файл, используя стандартное диалоговое окно и программа копирует этот файл в базу данных CityDesk.
Это превратилось в отличный пример того как "последний 1% кода занимает 90% времени". Первый набросок кода выглядел так:
Открыть файл
Прочитать его весь в большой массив байтов
Поместить этот массив в запись
Работало отлично. Для файлов разумного размера это происходило практически мгновенно. Там было несколько мелких ошибок, но я по очереди их исправил.
Большая Ошибка обнаружилась когда я проводил стресс-тестирование и перетащил файл размером 120 Мб в CityDesk. В наше время, люди вряд ли будут размещать 120-мегабайтные файлы на своих веб-сайтах. Но ведь и это возможно. Программа сработала, но работала почти минуту и ничем своей акивности не проявляла -- программа попросту замерла и выглядела зависшей. Это, конечно, не было идеальным решением.
С точки зрения интерфейса, что я действительно хотел для длительных операций, это вывести индикатор выполнения операции и кнопку "Отменить". В идеальном мире вы могли бы продолжать вашу работу, пока CityDesk выполняет копирование файла в фоновом режиме. Было три пути сделать это:
Из одного потока, проводя частые опросы входящих событий
Запустив второй поток и аккуратно синхронизируясь с ним
Запустив второй процесс и синхронизируясь с ним менее аккуратно
Мой опыт с №1 показывает, что это никогда не работает как надо. Очень трудно убедиться в том, что весь код вашей программы будет безопасно работать в то время, пока копируется файл. И убедил меня, что потоки обычно не такое хорошее решение, как отдельные процессы: безусловно, годы опыта показали мне, что программирование многопоточных приложений создаёт дополнительную сложность и даже привносит новые категории ошибок ужасно опасных ошибок типа "". №3 показался хорошим решением, особенно в свете того, что наша используемая база данных многопользовательская и ничего не имеет против множества процессов, одновременно работающих с ней. Так что это я и планирую сделать после того как вернусь из отпуска после Дня Благодарения.
Хотя, обратите внимание на общую картину. Мы ушли от простого чтения файла и сохранения его в базе данных к чему-то значительно более сложному: запустить дочерний процесс, приказать ему прочитать файл и сохранить его в базе данных, добавить индикатор выполнения и кнопку отмены дочернему процессу и обеспечить некий механизм, с помощью которого дочерний процесс сможет сообщить родительскому о том, что файл получен и может быть показан. Также придётся проделать некоторую работу по передаче аргументов дочернему процессу через командную строку, и убедиться что фокус окна ведёт себя как и ожидается, и предусмотреть случай, когда пользователь закрывает систему пока идёт копирование файла. Я бы предположил, что когда всё было бы сделано, у меня было бы в десять раз больше кода для обработки больших файлов -- кода, который, может быть, только 1% пользователей и увидят.
И, конечно, определённый тип программистов будет спорить, что моя новая архитектура с дочерними процессами стала хуже, чем была. Она "раздута" (из-за дополнительных строк кода). В ней больше возможностей для ошибок из-за дополнительных строк кода. Это "стрельба из пушки по воробьям". Скажут, что в некотором роде это показывает почему Windows такая плохая операционная система. Зачем все эти линейки прогресса? - спросят они. Просто нажмите Ctrl-Z, а потом несколько раз повторите "ls -l" и посмотрите растёт ли размер файла!
Возможно, это и не так уж необычно -- в нашем офисе много шурупов, которые не винчены точно по линейке. Проблема в том, что исправление этого уже после того, как отверстия просверлены -- необычайно дорого. Несмотря на то, что правильное положение шурупов всего в паре миллиметров от того как есть сейчас, вы не можете просто просверлить новые отверстия -- скорее всего вам придётся заменить всю дверь. Это не стоит того. Это как раз тот случай, когда исправление 1% ошибок займёт 500% усилий и объясняет почему в нашем мире столько много вещей хороших на 99%, а не на все 100%. (Наш архитектор не прекращает говорить об одном очень, очень дорогом доме в Аризоне, где каждый шуруп точно выверен.)
Это всё приводит к такой отличительной черте программы, которое большинство людей и считают мастерством. Когда программа написана действительно мастером -- все шурупы точно по линейке. Даже когда вы делаете что-то необычное, программа ведёт себя разумно. И больше усилий положено на обработку необычных случаев, чем в то, чтобы основной код просто работал. Даже если это займёт лишних 500% усилий чтобы решить 1% случаев.
Мастерство, конечно, невероятно дорого. Вы можете его себе позволить только если вы разрабатываете ПО для массовой аудитории. Жаль, но внутренний софт для управления персоналом, разработанный в страховой компании, никогда не достигнет этого уровня мастерства, потому что там просто недостаточно пользователей, чтобы окупить дополнительные затраты. А для небольшой компании, выпускающей ПО, этот уровень мастерства - это как раз то, что восхищает пользователей и обеспечивает долгосрочную конкурентоспособность, поэтому я и сделаю это правильно. Потерпите меня.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Назад, к основам
Автор: Джоэл Сполски
Переводчик: Дмитрий Майоров
Редактор: Александр Ширшов
11 декабря 2001 г.
Мы проводим немало времени, обсуждая на этом сайте разные восхитительные и грандиозные вещи, такие как противостояние .NET и Java, стратегия XML, привязывание клиентов, стратегия конкурентной борьбы, архитектура программного обеспечения, и т.п. Всё это напоминает слоёный пирог. Сверху лежит стратегия программного обеспечения. Под ней архитектуры вроде .NET, и ещё ниже - отдельные продукты: языковые средства разработки, как Java, или платформы вроде Windows.
Забуримся поглубже в пирог. Динамические библиотеки? Объекты? Функции? Нет! Глубже! В какой-то момент мы увидим строки программного кода.
Ещё глубже. Сегодня я хочу поговорить о процессорах. Маленький кусочек кремния, который байты двигает. Представим себе, что мы учимся программировать. Отложим знания об управлении проектами и языках высокого уровня и вернёмся к основам, заложенным ещё фон Нейманом. Забудем на минуту о J2EE. Подумаем о Байтах.
Так что сегодня наберитесь терпения, и давайте выполним небольшое упражнение на языке C.
Помните, как в C устроены : они представляют собой последовательность байтов, и последний байт всегда содержит особое значение 0. Это порождает два очевидных следствия:
Единственый способ определить, где строка кончается (то есть узнать её длину) - это пройти по ней в поисках нулевого байта в самом конце. Строка не может содержать нулевые байты. Так что хранить произвольные двоичные данные вроде картинки в формате JPEG в строке нельзя.
Почему строки в языке C так работают? А потому что микропроцессор PDP-7, на котором разрабатывались UNIX и C, имел такой строковый тип ASCIZ. ASCIZ означало "ASCII с нулём (zero) на конце."
Неужели это единственный способ хранить строки? Конечно нет, более того, это наихудший способ хранить строки. Для всех нетривиальных программ, API, операционных систем, библиотек классов следует избегать использования ASCIZ строк, как чумы. Почему?
Начнём с того, что напишем код функции strcat, которая прицепляет одну строку к другой.
void strcat( char* dest, char* src )
{
while (*dest) dest++;
while (*dest++ = *src++);
}
Посмотрим на код и разберёмся, что тут происходит. Сначала мы идём по первой строке и ищем её хвост (нулевой байт). После этого мы идём по второй строке и копируем её символы один за другим, добавляя их в хвост первой строки.
Такая работа со строками достаточно хороша для , но у неё есть свои проблемы. Вот проблема. Предположим, что у вас есть ворох имён и вы хотите их все сложить в одну длинную строку:
char bigString[1000]; /* Никогда не знаю, сколько выделить... */
bigString[0] = '\0';
strcat(bigString,"John, ");
strcat(bigString,"Paul, ");
strcat(bigString,"George, ");
strcat(bigString,"Joel ");
Это работает? Да. И выглядит чистенько и опрятно.
Как насчёт эффективности? Достаточно ли быстро это будет работать? А масштабируемость? Подходит ли такой код для обработки миллиона строк?
Нет. Этот код базируется на алгоритме маляра Шлемиэля. Кто такой Шлемиэль? Это персонаж из старого анекдота:
Маляр Шлемиэль подрядился красить пунктирные осевые линии на дорогах. В первый день он получил банку краски, поставил её на дорогу, и к концу дня покрасил 300 метров осевой линии. "Отлично!" сказал прораб, "быстро работаешь!" -- и заплатил ему копейку.
На следующий день Шлемиэль покрасил 150 метров. "Мда, это, конечно, не так здорово, как вчера, но приемлемо." -- сказал прораб и заплатил ему копейку.
На следующий день Шлемиэль покрасил 30 метров. "Всего лишь 30!" заорал прораб. "Это никуда не годится! В первый день было в десять раз больше! В чём дело?"
"Ничего не могу поделать," -- говорит Шлемиэль. "Каждый день я ухожу всё дальше и дальше от банки!"
Как с этим бороться? Многие хитрые программисты на C написали свою функцию mystrcat примерно так:
char* mystrcat( char* dest, char* src )
{
while (*dest) dest++;
while (*dest++ = *src++);
return --dest;
}
В чём разница? В том, что функция возвращает указатель на хвост новой длинной строки. Поэтому код, который вызывает эту функцию, может продолжать прицеплять без необходимости пробегать всю строку заново:
char bigString[1000]; /* Никогда не знаю, сколько выделить... */
char *p = bigString;
bigString[0] = '\0';
p = mystrcat(p,"John, ");
p = mystrcat(p,"Paul, ");
p = mystrcat(p,"George, ");
p = mystrcat(p,"Joel ");
Разумеется, производительность у этого кода линейная, а не квадратичная, поэтому он не так сильно тормозит при работе с большим количеством строк.
Разработчики языка программирования Паскаль были в курсе этой проблемы и "исправили" её, решив сохранять длину строки в первом байте. Такие строки называются паскалевскими. В них можно хранить произвольные двоичные данные, и у них нет замыкающего нулевого байта. Байт может принимать значения от 0 до 255, поэтому паскалевские строки не могут быть длиннее 255 байт. Поскольку у них нет нулевого байта на конце, они занимают в памяти ровно столько же места, как и ASCIZ строки. Одно из преимуществ паскалевских строк состоит в том, что не надо каждый раз пробегать по строке в поисках её конца. Длина строки определяется одной ассемблерной инструкцией вместо целого цикла. Это намного быстрее.
Старая операционная система Макинтошей использовала паскалевские строки повсюду. Многие программисты на C на других платформах использовали паскалевские строки для ускорения работы. Excel использует паскалевские строки внутри себя, поэтому строки во многих местах в Excel не могут быть длиннее 255 байт, и это одна из причин, почему Excel так быстро работает.
Традиционно для того, чтобы поместить паскалевскую строку в программу на C code, приходилось писать:
char* str = "\006Hello!";
Да, надо было посчитать байты вручную и забить полученное число в первый байт строки. Ленивые программисты иногда писали так (и получали медленные программы):
char* str = "*Hello!";
str[0] = strlen(str) - 1;
Обратите внимание, что в данном случае вы получаете строку, которая имеет замыкающий нулевой байт на конце (его добавляет компилятор), и при этом является паскалевской. Я использовал для таких строк термин fucked strings, потому что называть их паскалевские строки с нулевым байтом в конце очень длинно (мне можно, это канал для взрослых, вам придётся использовать более длинное название).
Я обошел вниманием важный момент. Помните эту строку?
char bigString[1000]; /* Никогда не знаю, сколько выделить... */
Раз уж мы сегодня разбираемся с битами, я не должен был это пропустить. Я должен был поступить в этом случае по правилам: определить, сколько байт мне потребуется, и выделить соответствующее количество памяти.
Правда?
Потому что иначе, понимаете, хитрый хакер, прочитав мой код, заметит, что я зарезервировал всего 1000 байт и надеюсь, что этого хватит, и он придумает оригинальный способ заставить мою программу strcat-нуть строку длиной 1100 байт в мои 1000 байт памяти, тем самым переписав стек, включая адрес возврата, так что когда функция вернётся, управление получит злобный код, который хакер сам написал. Именно это имеется в виду, когда говорят о том, что в очередной программе обнаружилось переполнение буфера . Одно время сетевые черви распространялись исключительно используя подобные способы, пока повсеместное распространение Microsoft Outlook не сделало написание сетевых вирусов доступным даже для подростков.
Вот, так что все эти программисты -- ламеры. Они должны были посчитать, сколько памяти потребуется.
Но вообще-то C не сильно тут помогает. Вернёмся к моему примеру с Beatles:
char bigString[1000]; /* Никогда не знаю, сколько выделить... */
char *p = bigString;
bigString[0] = '\0';
p = mystrcat(p,"John, ");
p = mystrcat(p,"Paul, ");
p = mystrcat(p,"George, ");
p = mystrcat(p,"Joel ");
Так сколько будем выделять? Попробуем по книжке.
char* bigString;
int i = 0;
i = strlen("John, ")
+ strlen("Paul, ")
+ strlen("George, ")
+ strlen("Joel ");
bigString = (char*) malloc (i + 1);
/* не забыть про замыкающий нулевой байт! */
...
Глаза б мои не видели. Вы, наверное, уже готовы переключить канал. Я понимаю, но подождите ещё чуть-чуть, потому что сейчас будет самое интересное.
Нам нужно пройти по всем строкам раз, чтобы определить, сколько места выделить, и затем ещё раз, чтобы их соединить. В случае с паскалевскими строками по крайней мере strlen выполняется быстро. Может, мы сможем написать версию strcat, которая будет самостоятельно выделять память.
Это отдельная песня: управление памятью. Вы знаете, как работает malloc? malloc поддерживает связный список свободных блоков памяти. Когда вы вызываете malloc, он проходит по списку в поисках блока достаточной длины. Найдя таковой, malloc разбивает его на две части (одна запрошенного размера, другая -- что осталось), кладёт остаток обратно в список свободных блоков, и возвращает указатель на блок запрошенного размера. Когда вы вызываете free, он просто добавляет освобождаемый блок в список свободных. Через какое-то время оказывается, что все свободные блоки маленькие, а нужен кусок побольше. Соответственно malloc объявляет перерыв и начинает перетряхивать список свободных блоков, сливая соседние маленькие блоки воедино, на что уходит три с половиной дня. В результате в среднем производительность malloc оказывается так себе (ему приходится постоянно ходить по цепочке свободных блоков), и иногда, внезапно, становится совсем никакой (когда приходится заниматься дефрагментацией). (Кстати, точно так же ведут себя и системы со сбором мусора, кто б мог подумать, так что заявления, которые часто можно услышать про неэффективность сборки мусора не совсем верны, ибо типичная реализация malloc обладает теми же самыми проблемами, хотя и в меньшей степени.)
Хитрые программисты борются с фрагментацией памяти, выделяя каждый раз память блоками, размер которых равен степени двойки. Ну вы знаете, 4 байта, 8 байт, 16 байт, 18446744073709551616 байт, и т.д. По причинам, которые должны быть очевидны для тех, кто играл с конструктором Lego, это уменьшает фрагментацию списка свободных блоков. Несмотря на то, что такой подход кажется расточительным, также легко показать, что при нём неиспользуемой остаётся не более чем 50% памяти. Так что ваша программа использует не более чем в два раза больше памяти, чем ей надо, что не так уж страшно.
Допустим, вы написали хитрую функцию strcat, которая изменяет по необходимости размер буфера для хранения результата. Сколько именно памяти ей имеет смысл выделять? Ровно столько, сколько сейчас надо? Мой учитель и наставник рекомендует при вызове realloc удваивать количество памяти по сравнением с прошлым разом. Это значит, что вам никогда не придётся вызывать realloc больше чем lg n раз, что неплохо с точки зрения производительности даже для огромных строк, и вы потратите впустую не больше 50% памяти.
Ладно. Жизнь в стране байтов становится всё сложнее. Правда, хорошо, что вам не надо больше ничего писать на C? В нашем распоряжении есть такие великолепные языки, как Perl, Java, VB и XSLT, которые не заставляют думать ни о чём таком низком, они сами со всем как-то справляются. Вот только иногда трубы вылезают в середине гостиной, и нам приходится думать о том, какой класс использовать -- String или StringBuilder, потому что компилятор всё ещё недостаточно умён, чтобы понять, чего же мы собственно хотим достичь, и помочь нам избежать попадания на алгоритм маляра Шлемиэля.
На прошлой неделе я написал, что команда SQL SELECT author FROM books не может быть быстро выполнена, если исходные данные находятся в формате XML. Если кто тогда не понял, о чём шла речь, то теперь, после целого дня ковыряния в байтах, вывод станет более очевидным.
Как реляционная база данных выполняет команду SELECT author FROM books? В реляционной базе данных каждая строка в таблице (например, в таблице books) имеет одинаковую длину в байтах, и каждое поле находится по фиксированному смещению относительно начала строки. Так что, например, если каждая запись в таблице books имеет длину 100 байт, и поле author находится по смещению 23, то имена авторов расположены начиная с байтов 23, 123, 223, 323, и т.д. Как выглядит код перехода на следующую запись? Примерно так:
pointer += 100;
Одна инструкция процессора. Ну очень быстро.
Теперь посмотрим на ту же таблицу в XML.
<?xml blah blah>
<books>
<book>
<title>UI Design for Programmers</title>
<author>Joel Spolsky</author>
</book>
<book>
<title>The Chop Suey Club</title>
<author>Bruce Weber</author>
</book>
</books>
Вопрос. Как выглядит код перехода на следующую запись?
Ээээ..
Тут толковый программист может сказать, ну давайте распарсим XML в памяти в дерево, по которому можно ходить туда-сюда относительно быстро. Объём работы, который придётся выполнить процессору, чтобы выполнить SELECT author FROM books расстроит вас до слёз. Как хорошо известно каждому разработчику компиляторов, лексический разбор и парсинг представляют собой наиболее медленные стадии компиляции. Достаточно сказать, что при разборе XML и построении дерева в памяти используется масса строковых операций, которые, как мы выяснили, медленные. И это при условии, что у вас есть достаточно памяти, чтобы запихать туда всё целиком. В случае реляционных баз данных время, необходимое для перехода от записи к записи фиксировано и определяется временем выполнения одной команды процессора . Просто по определению. И благодаря файлам, отражённым в память, вам надо будет загружать в память только те страницы, которые используются. В случае XML, если парсить заранее, то затраты времени на перемещение от одной записи к другой фиксированы, зато при этом время запуска большое, а если заранее не парсить, то время перехода от записи к записи зависит от длины записи и в любом случае это сотни процессорных инструкций.
Для меня это означает, что если надо работать с большими объёмами данных и при этом не терять в производительности, то использовать XML нельзя. Если данных немного, или то, что вы делаете, не обязано работать быстро, тогда XML годится. А если хочется и на ёлку влезть, и не оцарапаться, то придётся придумать способ хранить метаданные к XML, наподобие счётчика байтов в паскалевских строках, которые помогут быстрее находить, что где в файле лежит без необходимости всё разбирать. Но, конечно, редактировать такие файлы обычным текстовым редактором будет нельзя, потому что съедут метаданные, так что это уже будет неправильный XML.
Для тех трёх вежливых читателей, которые всё ещё со мной: надеюсь, вы узнали что-то новое или посмотрели на известные вещи с необычной стороны. Надеюсь также, что знание такого занудного материала первых занятий по информатике, как работа функций strcat и malloc, даёт вам новый угол зрения на высокоуровневые стратегические и архитектурные решения, которые вы принимаете в отношении технологий вроде XML. В качестве домашнего задания подумайте, почему процессоры от Transmeta всегда будут казаться подторможенными. Или почему исходная спецификация HTML-ного тэга TABLE была настолько плохо продумана, что большие таблицы не могут быть быстро отображены на экранах пользователей с модемами. Или почему COM так чертовски быстро работает, но только не в случае пересечения границ процессов. Или почему разработчики NT запихали драйвер дисплея в пространство ядра системы, а не в пользовательское пространство.
Всё это вещи, которые заставляют думать о байтах, и они оказывают влияние на архитектурные и стратегические решения, которые мы принимаем. Я придерживаюсь мнения, что студенты, начинающие изучать программирование, должны начинать с начала, использовать C и подниматься вверх от процессора. Мне противно, как часто программа обучения строится на посылке, что Java представляет собой хороший язык для того, чтобы начинать программировать, потому что это так "просто" и не нужно отвлекаться на эти скучные детали про строки и выделение памяти, и сразу можно изучить кульные ООП-штучки которые помогут сделать ваши большие программы так восхитительно модульными. Это педагогический провал. Поколения выпускников снисходят на нас, раскидывая алгоритмы маляра Шлемиэля налево и направо, даже не понимая этого, поскольку у них нет представления о том, что строки на нижнем уровне сложны, даже если из их перлового скрипта этого не видно. Если хочешь научить кого-то хорошо, надо начинать с основ. Как в Karate Kid. Wax On, Wax Off. Wax On, Wax Off. Повторять три недели. После этого Снести Башню Другому Пацану несложно.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Не просто удобство использования
Автор: Джоэл Сполски
Переводчик: Анар Мустафаев
06 сентября 2004
Годы и годы, самосформировавшиеся ученые мужи, такие, хех, как я, без конца болтают о практичности (usability) и о том, как важно сделать программное обеспечение удобным в использовании. Джакоб Ниелсен (Jakob Nielsen) приводит математическую формулу, которую он раскроет вам за $122, с помощью которой вы сможете подсчитать степень практичности. (Если ожидаемое значение больше $122, то, я думаю, вы получите прибыль).
В этой книге, на странице 31 я привожу пример, в то время, самой популярной программы на Земле – Napster. В главном окне этой программы для переключения между пятью экранами использовались кнопки. Согласно принцину доспупности (affordance) вместо кнопок в программе должны были быть вкладки (tabs), что я и объясняю.
И все же, Napster был самой популярной программой на Земле.
В более ранней версии рукописи, я написал что-то типа: “это просто показывает вам, что удобство использования, все же, не так важно”, что было бы лишним писать в книге о практичности программного обеспечения. Я несколько успокоился, когда наборщик сообщил мне, что мне необходимо уменьшить этот параграф. Поэтому я удалил это предложение.
Но здесь есть пугающий элемент истины – пугающий, как минимум, для профессионалов пользовательского интерфейса: приложение, которое делает что-то действительно классное, которое люди действительно хотят, может быть душераздирающе неудобным в использовании, но оно все равно будет хитом. И наоборот, приложение может быть самым простым в использовании, но если оно не делает ничего, что было бы кому-то нужно, оно потерпит неудачу. Консультатнты по пользовательскому интерфейсу всегда защищены, разрабатывающие улучшаемые формулы возвращения инвестиций для своих клиентов, они всегда получат свои $75,000 за проект улучшения практичности, потому что практичность воспринимается как нечто “опциональное”, и страшная вещь состоит в том, что во многих случаях это так и есть. Во многих случаях. Сайт CNN ничего не выиграл бы от привлечения консультанта по пользовательскому интерфейсу. Я рискну предположить, что это не единственный контекстный веб-сайт, который не заработал бы и доллара от улучшения пользовательского интерфейса, потому что контекстные веб-сайты (я имею в виду, что они не являются приложениями) уже чертовски удобны в использовании.
И все же.
Моя цель сегодня не хныкать о том, что практичность не важна... практичность важна на границах, полно примеров когда неудобство использования убивает людей в небольших самолетах, создает голод и эпидемию и т.д.
Моя цель сегодня - поговорить о следующем уровне проектирования программного обеспечения, после того как у вас есть правильный пользовательский интерфейс: создании социального интерфейса.
Я думаю, я должен это объяснить.
Все программное обеспечение в 80-х годах, когда практичность была “изобретена”, использовалось для взаимодействия между человеком и компьютером. Много программ и сейчас используюся таким же образом, но интернет принес нам новый тип программ: программ, которые предназначены для взаимодействия человек-человек.
Когда вы пишите программу, которая является посредником между людьми, после того как у вас правильный пользовательский интерфейс, у вас должен быть правильный социальный интерфейс. И социальный интерфейс более важен. Лучший в мире пользовательский интерфейс не спасет программу если у нее будет неуклюжий социальный интерфейс.
Лучший способ проиллюстрировать социальные интерфейсы – это привести несколько примеров неудач и успехов.
Несколько примеров.
Первый, неудачный пользовательский интерфейс. Каждый день я получаю электронной письмо от кого-то, о ком я никогда не слышал, призывающее меня стать членом его сетевого сообщества. Я чувствую себя несколько раздраженно, потому что, обычно, я не знаю этого человека и удаляю письмо. Кто-то сказал мне, почему это происходит: некоторые из компаний, содержащие эти сети, имеют инструмент, который пробегает по вашей адресной книге и посылает электронной письмо каждому из списка адресов призывая присоединиться к ним. Теперь добавьте сюда свойство некоторых программ для работы с электронной почтой коллекционировать адреса всех тех, кто писал вам и то, что вы получаете письмо-подтверждение, когда подписываетесь на бюллетень Joel on Software и вуаля: люди, которых я не знаю, запускают программы, которые непреднамеренно просят меня подтвердить что я их друг. Спасибо за то что подписались на мою рассылку, но нет, я не собираюсь представлять вас Биллу Гейтсу. Сейчас у меня есть правило не вступать ни в какие сетевые сообщества, потому что они бьют по самой сути работы сообществ сети.
Теперь давайте посмотрим на удачный социальный интерфейс. Много людей менее закомплексованны когда они стучат по клавишам, чем когда они говорят лицом к лицу. Тинейджеры менее стеснительны. С помощью текстовых сообщений они скорее пригласят кого-нибудь на свидание. Этот вид программ был настолько успешен социально, что он радикально улучшил любовную жизнь миллионов людей (или, как минимум, их светские календари). Даже несмотря на то, что обмен текстовыми сообщениями имеет ужасный пользовательский интерфейс, это стало чрезвычайно популярным у детей. Шутка состоит в том, что гораздо лучший пользовательский интерфейс встроен в каждый сотовый телефон для коммуникации между людьми: эта замечательная вещь называется “телефонные звонки”. После набора телефонного номера, все что вы скажите, услышит другой человек и наоборот. Это просто. Но это не так популярно в некоторых кругах, чем неуклюжая система, в которой вы ломаете большой палец набирая огромные строки номеров, чтобы сказать “черт ты горячая”, потому что строка цифр приведет вас на свидание, и у вас никогда не хватит кишки сказать “черт ты горячая” вашими голосовыми связками.
Другой пример успешного социального интерфейса это ebay. Когда я первый раз услышал о ebay, я сказал: “Ерунда! Это никогда не будет работать. Никто не будет посылать свои деньги какому-то человеку, случайно встреченному в интернете, который бы оказался настолько добр чтобы прислать какие-то товары.” Много людей думали также. Мы все были не правы. Не правы, не правы, не правы. Ebay сделал большую ставку на культурную антропологию человеческого бытия и выиграл. Великая вещь заключается именно в том, что это был большой успех именно потому, что, в то время, это было похоже на сумашедшею идею, поэтому никто ничего такого не пытался делать, пока ebay пользовался преймуществом первопроходца, застряв в эффектах сети.
В дополнение к абсолютным успехам и неудачам есть еще и побочные явления социального программного обеспечения. То как ведет себя социальное программное обеспечение, в большой мере, определяет как будет вести себя сообщество которое им пользуется. В клиентских программах USENET есть команда - большое-R, которая используется для ответа на сообщение цитируя первоначальное сообщение этими элегантными > (правая угловая скобка) в левой клонке. Раньше у читателей новостей не было отдельных потоков для тем, поэтому если вы хотели ответить на чье-то сообщение вразумительно, вы должны были пользоваться этой большой R. Это привело к особенному USENETовскому стилю ответа, построчному мелочному придирничеству (line-by-line nitpick). Это удобно для придиралы (nitpicker), но всегда неудобно для чтения. (Кстати политические блогеры, новички в интернете, заново изобрели эту технику, думая что они открыли что-то классное и новое, называют это фискинг (fisking), по причинам, в которые я не буду углубляться. Не волнуйтесь, они ни непристойны.) И хотя человечество ведет свои дискусии на протяжении столетий, маленькая особенность программного продукта породила абсолютно новый стиль дискуссии.
Маленькие изменения в программе могут повлечь большие изменения в том, как программа выполняет, или терпит неудачу в выполнении, своих социальных целей. Дана Бойд (Danah Boyd) сильно критикует социальные программные сети, , разбивая в пух и прах сегодняшнее поколение этого программного обеспечения, заставляющее пользователей вести себя подобно умственно неполноценным:
Посмотрите, на мгновение, на недавний всплеск интереса к социальным сетям, таким как Friendster, Tribe, LinkedIn, Orkut и им подобным. Эти технологии пытаются формализовать то, как люди должны создавать и управлять своими отношениями с другими людьми. Они допускают, что вы можете выставить оценку своим друзьям. В некоторых случаях они слишком формально прямы в том смысле, как люди общаются с новыми людьми, предлагая некоторый абсолютный механизм через который вы можете установить контакт.
Хотя этот подход имеет свои достоинства, потому что это численно возможно, меня ужасает когда люди считают, что это моделирует социальную жизнь. Это так упрощенно, когда людей заставляют общаться процедурно, как будто бы у них аутизм. Этот подход определенно помогает тем людям кому нужна такая систематизация, но это не та универсальная модель, которая бы имела смысл. Кроме того, каковы последствия того, что данная технология предлагает механистическое приглашение? Действительно ли мы хотим социальную жизнь, которая бы содействовала умственно неполноценному общению?
Когда программа реализует социальные интерфейсы не учитывая культурную антропологию, это вызывает страх, этим не удобно пользоваться и, в действительности, это не работает.
Создание социального интерфейса.
Позвольте мне привести пример создания социального интерфейса.
Предположим ваш пользователь сделал что-то, что он не должен был делать.
Хороший, практичный дизайн объясняет, что вы должны сказать им, что они делают не так и как это можно исправить. Консультанты по удобству использования предлагают это под маркой «Защищенный дизайн».
Когда вы работаете над социальным программным обеспечением, это слишком наивно.
Возможно вещь, которая была сделана неправильно, это опубликовать рекламу Viagra на форуме.
А теперь скажите им: “Извините, но Viagra запрещенная тема. Ваше сообщение удалено.”
Знаете, что они сделают?
Они разместят рекламу V1agra. (Либо это, либо начнут длинные скучные разглагольствования о цензуре и Первой Поправке.)
Работая над социальным интерфейсом, вы должны использовать социологию и антропологию. В сообществах есть и лодыри,и халявщики, и другие злодеи. В социальном программном обеспечении, найдутся люди, которые попытаются злоупотребить программой ради своей выгоды и за счет остального сообщества. Необузданное, это ведет к тому, что экономисты называют трагедией простого народа.
Несмотря на то, что цель дизайна пользовательского интерфейса помочь пользователю, цель дизайна социального интерфейса помочь сообществу, даже если это означает неудачу одного пользователя.
Поэтому хороший дизайнер социального интерфейса может сказать, давайте не будет показывать сообщение об ошибке. Давайте притворимся, что сообщение о Viagra было принято. Покажем его только отправителю, он почувствует себя довольным и перейдет на следующий неподходящий форум. Но больше мы никому не покажем это сообщение.
Действительно, один из лучших способов отклонить аттаки - это показать видимость, что они удались. Это программный способ притвориться мертвым.
Нет, это не работает в 100% случаев. Это работает в 95% случаев, и это уменьшает ваши проблемы раз в двадцать. Подобно всему остальному в антропологии, это нечеткая эвристика. Это работает в большинстве случаев, поэтому это стоит сделать, даже если нет гарантии полной защиты. Русская мафия со своими хитроумными схемами, в конечном счете, разберется с этим. А какой нибудь идиот из Флориды, сидящий в трайлерном парке и пытающийся разбогатеть, попадется. 90% спама, который я получаю сегодня настолько безнадежно наивен, что может быть отсеян даже умилительным фильтром встроенном в Microsoft Outlook. У вас там попадется самый дурацкий спам, который может быть пойман этим поверхностным знанием поисковых фраз.
Маркетинг социальных интерфейсов.
Несколько месяцев назад я обнаружил, что общая тема, которая используется в программах построенных в Fog Creek, почти всегда захватывает внимание настолько, что вызывает желание пользоваться правильными социальными интерфейсами. Например, в FogBugz (features), и еще больше не-особенностей (non-features), сделаных для того чтобы программой действительно пользовались для отслеживания ошибок. Снова и снова клиенты говорят мне, что их старое программное обеспечение для отслеживания ошибок не использовалось, потому что оно никак не стыковалось с тем как люди хотят работать вместе, но когда они развернули FogBugz, люди стали использовать ее, и привыкли к ней, и это изменило то как они работают вместе. Я знаю, что FogBugz работает, потому что у нас очень большая степень обновления, когда выходит новая версия, что говорит мне, что FogBugz - это программа не для книжной полки (shelfware), и еще потому что даже те клиенты, которые покупают много лицензий, снова возвращаются за новыми пользовательскими лицензиями, ведь продукт распространяется внутри организации и реально используется. Это именно то, чем я горжусь. Программы для совместного использования в команде обычно терпят неудачу, потому что требуют от каждого члена команды изменить способы совместной работы, а это как раз то, что антропологи считают наименее возможным. По этой причине в FogBugz масса дизайнерских решений призванных сделать удобным использование даже для одного члена команды, и множество особенностей дизайна, которые понемногу поощряют других членов к использованию этой программой до тех пор пока все не будут пользоваться ею.
используемое на этом сайте, которое скоро будет продаваться как дополнительная опция FogBugz 4.0, еще более требовательно к правильной реализации подходов социальных интерфейсов. В нем масса особенностей, не-особенностей и дизайнерских решений, которые все вместе приводят к высокому уровню интересной дискуссии с лучшим соотношением полезный сигнал-шум для любого форума, в котором я принимал участие. Я много писал об этом в моей статье .
С тех пор я еще более предан идее хорошего проектирования социального интерфейса: мы привлекаем экспертов, таких как Клэй Ширки (Clay Shirky) (пионер в этой области), мы проводим смелые эксперименты над гражданами форума Joel on Software (многие из которых незаметны для того чтобы быть виртуально недоступными, например, мы не показываем ваше сообщение до тех пор пока вы не уберете все цитаты для лучшего восприятия), мы много вкладываем в передовые алгоритмы призванные уменьшить спам на форуме.
Новая область.
Разработка социального интерфейса пока все еще находится в периоде становления. Я не знаю никаких книг на эту тему; только несколько людей работают над исследованиями в этой области, и пока еще не сформирована наука проектирования социального интерфейса. В ранние дни проектирования удобства использования программ, софтверные компании нанимали экспертов по эргономике и человеческому фактору, чтобы они помогли спроектировать удобные продукты. Эксперты по эргономике много чего знают о правильной высоте стола, но они не знают как разрабатывать графические пользовательские интерфейсы для файловых систем, потому то и возникла новая область. Со временем новая дисциплина вступила в свои права и провозгласила такие концепции как: логичность, доступность, обратная связь и другие, которые стали краеугольным камнем в науке проектирования пользовательского интерфейса.
В течении следующего десятилетия, я думаю, софтверные компании наймут людей обученных антропологии и этнографии, чтобы работать в области проектирования социального интерфейса. Вместо того чтобы строить лаборатории по практичности, они пойдут в народ и напишут этнографии. И, будем надеяться, мы определим новые принципы проектирования социального интерфейса. Это обещает быть пленительным... таким же веселым как дизайн пользовательского интерфейса был в 1980-х... поэтому не расслабляйтесь.
Обсудите эту тему на Joel on Software .
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Ну откуда все эти (неоригинальные) мысли?
Автор: Джоэл Сполски
Переводчик: Семён Хавкин
Редактор: Юрий Удовиченко
19 апреля 2000
Стоило бы, наверное, назвать эту статью: "Почему мне пора перестать читать журнал Upside". Я и правда пытался, но мне его шлют бесплатно, и надо же что-то читать в туалете, так что я его взял и обнаружил там одну из глупейших за долгое время статей. То-есть, на самом деле, Upside полон глупостей, но эта была уж слишком откровенная.
Статья написана Стефеном Джеймсом и называется "Уроки выживания" (Upside, март 2000 года). Теперь, говорят нам, каждый месяц мистер Джеймс будет делиться с нами "шишками, которые [он] набил на [своих] собственных стартапах".
Шишки эти состоят из исключительно полезных советов, до которых ни за что своим умом не дойдёшь. Типа: не выбрасывайте деньги на рабочие площади; найдите себе район, где нету длинных очередей в кафе. Если вы организуете дот-ком, мистер Джеймс напоминает: "Выйдите из дому... Работать дома неклёво." Он также отмечает, что не следует платить больше полутора долларов за квадратный фут. Спасибочки, мистер Джеймс! Что ж, по-вашему, на всех рынках одни и теже цены? Может быть, он просто думает, что все на свете открывают компании только в Силиконовой долине.
"Забудьте про бесплатный кофе и боржом. Да, в Майкрософте их дают бесплатно... кто ж хочет быть похожим на Майкрософт?"
Чего? Это такая шутка? Upside решил в мае отметить 1 апреля?
Мне кажется, мистер Джеймс живёт в заоблачном мире, где миллионы программистов просто давятся к вам на работу. Основателям компании хочется обойтись без излишеств; это кажется пустой тратой денег. Пусть так. Но не думайте, что кандидаты к вам на работу также всей душой к ней привяжутся; этого не будет. Им нужно приятное место работы. Отказаться от бесплатных напитков, принятых в большинстве технических компаний, значит дать понять работникам — и потенциальным работникам — что удобство их работы вас не беспокоит.
Кажется, все в Долине судачат о Чарли, шеф-поваре в , который раньше работал у . Скажу вам, еда там замечательная даже по стандартам , не каких-нибудь кафетериев. А поскольку еда в столовке такая хорошая, народ на обед не уходит с работы . Они едят с коллегами, заодно обсуждая дела. На работу они возвращаются через полчаса после ухода, что способствует продуктивности труда. Они чувствуют, что Гугл о них заботится, и это повышает лояльность рабочей силы.
Тем временем, Стефен Джеймс нам сообщает: "Перегородки — плохая идея. Не ставьте стен или ширм — оставьте открытое пространство... Если работник хочет кабинет с дверью, пусть идёт в адвокатуру или в Эппл."
Знаете, они-таки уйдут в Эппл! И замена каждого из них будет стоить порядка 50 тысяч на поиск и обучение. А вот мой приятель предлагает своим программистам превосходные личные кабинеты в одном из самых дорогих деловых районов США на Манхеттене, и это стоит ему около 6 тысяч на год с носа. В общем и целом, не так много.
Что ещё хуже, мистер Джеймс, похоже, совершенно незнаком с документальными доказательствами того, что при подходящих условиях работы — свободное пространство, тишина, ... — у работников умственного труда возрастает производительность. Классическая книжка по руководству программистами Peopleware приводит огромное количество таких доказательств. (По справедливости, мистер Джеймс в своём невежестве не одинок. Он просто отражает народную мудрость, типичную для Долины.)
Вот где собака порылась. Все мы прекрасно знаем, что работникам умственного труда лучше всего работается, когда они погружаются "в зону концентрации", или, так сказать, в "трудовой поток", полностью концентрируются на задаче и отключаются от внешних воздействий. Они забывают о времени, и в состоянии чрезвычайной сосредоточенности выдают на-гора превосходные результаты. Вот в такие периоды всю свою творческую работу они и делают. Писатели, программисты, учёные, даже баскетболисты многое знают об этой зоне.
Однако же, войти в "зону" нелегко. Измерения показывают, что с начала работы максимальная продуктивность достигается в среднем за 15 минут. А если кто устал или уже как следует поработал головой, то, бывает, никак не может войти в зону, и проводит остаток дня в интернете, играет в тетрис, бьёт баклуши.
С другой стороны, выйти из зоны очень легко. Шум, телефонные звонки, сходить пообедать или сгонять в Старбакс за чашечкой кофе, назойливость сотрудников — ох уж эти сотрудники — всё выбивает из колеи. Если коллега прерывает вас своим вопросом на минутку, и тем самым сбивает вашу концентрацию на полчаса, общая продуктивность труда серьёзно страдает. А в шумной, нервозной атмосфере, вроде того базара, что царит в интернет-изданиях, когда продавцы-маркетоиды орут в телефон прямо над ухом программиста, производительность труда резко падает, потому что творческие работники находятся не в зоне концентрации, а в зоне постоянных помех.
Программистам особенно тяжело. Их труд основан на одновременном жонглировании в кратковременной памяти огромным количеством мелких деталей. Всякое прерывание сбивает жонглёра, и шары с грохотом летят вниз. А потом деталей этих никак не вспомнить (как называется эта переменная? в каком месте вылетает цикл?) и приходится шарить по полу в поисках нужного шара, и работа застопорится, пока вы не соберёте всё.
Теперь немного арифметики. Предположим (и это подтверждается опытом), что если мы прерываем работу программиста хотя бы на минутку, он на самом деле теряет 15 минут производительного времени. Дано: Петя и Вася работают за соседними столами в фирме Просиживателей Штанов стандартной конфигурации. Вася забыл, как называется юникодова версия функции копирования строк. Он может поискать ответ в компьютерном справочнике, на что уйдёт 30 секунд. Или он может спросить Петю и получить ответ через 15 секунд. Раз Петя у него под рукой, он к нему и обратится. Петя отвлечётся и потеряет 15 минут рабочего времени, чтобы сэкономить Васе 15 секунд.
Давайте переведём Васю и Петю в отдельные кабинеты, разделённые стенами и дверями. На поиск в справочнике у Васи уходит по-прежнему 30 секунд, но до Пети ему теперь 45 секунд, включая отрыв седалища от сиденья стула (занятие не из лёгких, учитывая общую физическую подготовку типичного программиста). Что сделает Вася на этот раз? Правильно, посмотрит название в справочнике. Он потеряет 30 секунд, но сэкономит Пете 15 минут производительного времени. Так-то!
А впрочем, я нисколько не сомневаюсь, что большинство читателей подумают: "Какого чёрта ты вообще читаешь Upside? Вот и получай." Что верно, то верно. Так мне и надо.
Примечания переводчика.
Джерри Гарсия был легендарным солистом легендарной рок-группы Grateful Dead.
Это клевета, будто программисты плохо физически подготовлены. Многие из них очень неплохо знают физику! Хотя постойте...
На языке оригинала выражению "в зоне концентрации" соответствует in the flow. Рекомендуется к изучению.
Стандарты Мишелина: речь идёт не о шинной промышленности, а о путеводителе по ресторанам.
Старбакс, хоть и такая-сякая глобальная корпорация, но варит неплохой кофе!
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
О вреде многозадачности применительно к людям
Автор: Джоэл Сполски
Переводчик: Дмитрий Майоров
12 февраля 2001 г.
Одно из первых дел, которое приходится осваивать при управлении командой программистов, это распределение фронта работ. Что на нормальном языке означает сказать, кому что делать. В разговорном иврите есть соответствующий фразеологический оборот, в примерном переводе означающий "разбрасывание папок" (потому что вы подкидывете папки людям на колени). То, как вы решаете, какие папки окажутся на чьих коленях, может сильно увеличить производительность, если сделать это правильно. А если нет, то может получиться одна из тех неприятных ситуаций, когда никто ничего толком сделать не может и все жалуются, что "сплошной бардак и фиг что тут поделаешь".
Поскольку этот сайт для программистов, для разминки я предложу программистскую задачку.
Предположим, что у вас есть две отдельных вычислительных задачи (A и B), которые нужно выполнить. Каждая задача требует для полного выполнения 10 секунд процессорного времени. В вашем распоряжении есть один процессор, и для упрощения будем считать, что других задач в очереди нет.
На нашем процессоре многозадачность необязательна. Так что вы можете выполнить вычисления по очереди...
Последовательная обработка
... или использовать переключение между задачами. В последнем случае на нашем конкретном процессоре задачи выполняются по одной секунде за раз, и время переключения пренебрежимо мало.
Многозадачность
Какой вариант вы выберете? Первая реакция у большинства людей: многозадачность лучше. В обоих случаях для получения обоих ответов придётся ждать 20 секунд. Но давайте подумаем, сколько времени придётся ждать каждого ответа по отдельности.
В обоих случаях от момента начала вычислений до получения результата B (синий цвет) пройдёт 20 секунд. Но посмотрите на задачу A. При использовании многозадачности с момента начала вычислений до получения её результата прошло 19 секунд... тогда как при последовательной обработке результат был готов через 10.
Иными словами, в этом удачно притянутом за уши примере среднее время меньше (15 секунд вместо 19.5) при последовательной обработке, чем при многозадачности. (Вообще-то этот пример не так уж сильно притянут -- он основан на реальной проблеме, которую Джареду пришлось решать на работе).
20.5 секунд
28 секунд
80 секунд
1099 секунд
Само по себе это не слишком революционная мысль, не правда ли? Скоро я стану получить злые письма от деятелей, обвиняющих меня в том, что я "против" многозадачности. Будут ехидно спрашивать "что, хочется обратно во времена DOS, чтобы обязательно выходить из WordPerfect, прежде чем запустить Lotus 1-2-3?"
Но я не про это. Я всего лишь хочу, чтобы вы согласились, что при данном примере:
а) последовательная обработка обеспечивает в среднем более быстрое получение результатов, и
б) чем дольше переключение между задачами, тем больше потери времени от многозадачности.
Хорошо, возвращаемся к более интересной теме управления людьми, а не процессорами. Особенность тут в том, что у программистов переключение между задачами происходит очень, очень, очень долго. Потому что это такое занятие, при котором приходится держать в голове много всякой всячины одновременно. Чем больше, тем быстрее движется работа. Программисту, работающему в полную силу, приходится удерживать в голове миллион разных вещей: названия переменных, структур данных, системных вызовов и вспомогательных функций, которые были ранее написаны и часто используются, даже название подкаталога, где живут исходники. Если послать этого программиста на три недели в отпуск на остров Крит, то он всё это забудет. Человеческий мозг, похоже, при первой возможности высвобождает оперативную память, сбрасывая её содержимое на ленту, откуда всё это потом очень долго доставать.
Насколько долго? Например, недавно на три недели бросила всё (а именно разработку программного продукта под кодовым названием CityDesk), чтобы выручить клиента, которому внезапно потребовалось наша помощь. Когда мы вернулись в контору, потребовалась почти неделя, чтобы набрать обычную скорость работы над CityDesk.
Вы лично никогда не замечали, что даешь человеку задание, и он его отлично выполняет, но даёшь два задания одновременно, и результат гораздо хуже? Он либо делает одну работу и забывает про другую, либо пытается делать обе, но настолько медленно, что улитки обгоняют. Это потому, что переключение между программистскими задачами происходит медленно. Если у меня на столе два проекта одновременно, то переключение отнимает часов шесть. При восьмичасовом рабочем дне остаётся два часа производительного времени. Негусто.
Выясняется, что если вы поручили кому-то два задания одновременно, скажите спасибо, если этот кто-то "придушит" одну из задач, чтобы получить возможность работать над другой, потому что в этом случае результат будет раньше. Мораль всего этого в том, что не следует давать людям работать более, чем над одной задачей одновременно. Убедитесь в том, что они это знают. Хорошие менеджеры считают своей обязанностью устранение препятствий, мешающих людям концентрироваться на одном деле и добиваться результатов. Когда появляются неожиданные вводные, подумайте, не можете ли вы разобраться с ними самостоятельно, прежде чем поручать программисту, который сидит по уши в коде другого проекта.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
О вреде премирования
Автор: Джоэл Сполски
Переводчик: Дмитрий Майоров
Редактор: Пётр Гладких
3 апреля 2000
Майк Мюррей (Mike Murray), на редкость невезучий кадровик компании Microsoft, отличался неоднократно, не считая создания приза "За поставку продукта на-гора" ("Ship It" award), который был учрежден им в самом начале карьеры. Идея заключалась в том, что сразу после выпуска продукта вы получаете надгробную плиту размером с приличный словарь. Это каким-то образом должно было давать стимул к работе, потому как если вы ничего не делаете, то ведь никакого люсита не будет! Удивительно, как фирме Microsoft вообще удавалось выпускать программы до появления этой плиты.
Приз был объявлен под невероятный гром фанфар на большом компанейском пикнике. За несколько недель до этого всему кампусу корпорации были развешены плакаты с портретом Билла Гейтса и подписью "Почему этот человек улыбается?". Я не совсем тогда понял, что именно имелось в виду. Билл улыбается потому, что у нас теперь есть стимул создавать программы? На пикнике стало очевидным, что сотрудники компании чувствовали, что к ним относятся как к детям, и освистали выступавших. Команда Excel развернула огромный транспарант с лозунгом: "Почему команда Excel зевает?". О том, как этот приз был презираем, говорит тот факт, что в основанном на реальных событиях эпизоде классической книги Дугласа Коплэнда (Douglas Coupland) в которой группа программистов пытается .
Отношение к собственным высококвалицированным учёным, как к детям, которые ещё в детский сад ходят - это далеко не уникальное явление. Почти в каждой компании есть подобная весьма обидная и оскорбительная программа премирования.
В двух компаниях, где я работал, наибольший стресс приходился на время обязательной аттестации, которая проводилась раз в полгода. Отделы кадров Juno и Microsoft, по-видимому, списали системы аттестации и премирования из одной и той же Дилбертовской книги по управлению, потому как обе работали совершенно одинаково. Сначала каждый сотрудник "анонимно" оценивал своего прямого начальника (как будто это можно было сделать честно и объективно), потом заполнял необязательный бланк "самооценки", который начальник "учитывал" при проведении аттестации, заключавшейся в проставлении оценок в качественных категориях вроде "хорошо работает в команде" по пятибальной шкале, причём, в действительности, допустимы были только оценки 3 и 4. Менеджеры предоставляли предложения по премированию наверх, где они полностью игнорирвались, и в результате все получали премиальные случайного размера. Эта система никогда не принимала в расчёт тот факт, что у людей есть разные и уникальные таланты, которые необходимы для хорошей работы команды в целом.
Аттестация порождала стресс по двум причинам. Многие из моих друзей, особенно те из них, кто обладал талантами которые были очень важны, но не попали в традиционный список на бланке, получали паршивые аттестационные оценки. Например, один из них был жизнерадостным катализатором, своего рода тамадой, помогая каждому, когда дела шли плохо. Он был своеобразным клеем, который удерживал команду вместе, и при этом каждый раз получал неважные результаты аттестации просто потому, что начальник его недооценивал. Другой знакомый обладал невероятным стратегическим чутьём; его участие в обсуждении технических вопросов помогало всем остальным делать работу намного лучше. Он тратил времени боольше среднего на то, чтобы пробовать новые технологии, и в этой области он был очень полезен для всей команды. Но, учитывая число строк написанного кода, он оказывался позади, и поскольку начальник по своей глупости ничего другого не замечал, результаты аттестаций тоже были никудышные. Что, конечно, плохо сказывалось на настроении. Более того, даже положительная оценка может оказаться обидной, если она не настолько положительная, как человек ожидал.
Влияние аттестаций на настроение сотрудников несимметрично: отрицательные оценки сильно обижают людей, а положительные никак не влияют ни на настроение, ни на производительность. Те, кто их получает, и так работают хорошо. Положительная оценка намекает, что они прогибаются, чтобы получить похвалу... как собаки Павлова, работающие за подачку, а не как профессионалы, действительно заботящиеся о качестве своей работы.
И именно тут собака зарыта. Большинство людей считает, что они работают очень хорошо (даже если это совсем не так). Это такой фокус, который наш мозг сам себе показывает, чтобы жизнь не казалась совсем уж невыносимой. Так что каждый думает, что работает хорошо, и даже если аттестация проведена справедливо (что непросто), большинство людей будет разочаровано результатами. Влияние этого на настроение коллектива трудно не заметить. В командах, где аттестации проводятся честно, они приводят к неделе-другой всеобщей депрессии, и иногда увольнениям по собственному желанию. Они вбивают клинья между членами коллектива, часто из-за зависти, что называют непереводимым термином teamicide (team - команда, а teamicide - созвучно suicide - самоубийство): непреднамеренный развал ранее сплочённых команд.
Альфи Кон (Alfie Kohn) в уже ставшей классической статье в журнале Harvard Business Review пишет:
... по крайней мере два десятка исследований за последние тридцать лет определённо показывают, что люди, ожидающие получить награду за выполнение задания или за успешную работу просто не работают так же хорошо, как те, кто не ожидает какого-либо поощрения. []
Он приходит к выводу, что "премии (или взятки) просто неэффективны на рабочем месте". ДеМарко и Листер идут дальше и недвусмысленно отмечают, что любой вид соревнований на рабочем месте, любая схема кнута и пряника, и даже старый трюк "поимки людей с поличным за деланием чего-то полезного с последующим награждением" -- все они приносят больше вреда, чем пользы. Любая раздача пряников (например, церемониальное вручение мемориальных досок победителям соцсоревнования) подразумевает, что они работали, чтобы получить эту люситовую доску; то есть они не обладают достаточной самостоятельностью, чтобы работать не за пряник; это унизительно и обидно.
В большинстве случаев у менеджеров нет выбора и они вынуждены участвовать в существующих процедурах аттестации. Если вы находитесь в такой ситуации, единственный способ избежать "убийства команды" - это проставить всем максимальные оценки. Если же у вас есть выбор, то я рекомендую избегать всяческих аттестаций, премий и вымпелов "ударнику месяца".
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Огонь и движение
Автор: Джоэл Сполски
Переводчик: Алексеем Симоновым
Редактор: Маратом Зборовским
6 января, 2002
Иногда я просто не могу ничего сделать.
Конечно я прихожу в офис, слоняюсь без цели, проверяю электронную почту каждые 10 секунд, хожу по Сети, даже делаю несколько дел, не требующих интеллекта, наподобие оплаты счета от American Express. Но возвращения в поток непрерывного написания кода не происходит.
Эти приступы непроизводительности обычно продолжаются день или два. Но бывали времена в моей карьере разработчика, когда я ходил недели напролёт не в состоянии чего-либо сделать. Говорят что я не в потоке. Я не в зоне. Я нигде.
Каждый из нас подвержен переменам настроения. У одних они лёгкие, у других более резко выраженные или даже выводящие из строя. И приступы непроизводительности кажется связаны каким-то образом с унылым настроением.
Это заставляет меня думать о тех исследователях, которые говорят, что в основном люди не могут контролировать, что они едят. Таким образом любая попытка соблюдать диету вынуждена быть непродолжительной и они всегда возвращаются обратно к своему естественному весу. Возможно, как разработчик программ, я действительно не могу контролировать когда я производителен, и мне остаётся только принять как данность как продуктивные так и непродуктивные периоды и надеяться что в среднем они выразятся в достаточном количестве строк кода, чтобы сделать меня привлекательным для работодателей.
Но что просто выводит меня из себя, так это то, что ещё на первой моей работе я понял - производительное кодирование отнимает у меня, как разработчика, в среднем по два-три часа в день. Когда я проходил летнюю стажировку в Microsoft, мой приятель сказал, что на самом деле он находится на работе с 12 до 5 каждый день. Пять часов минус обед - и его команда буквально любила его за то, что, несмотря на это, он умудрялся сделать гораздо больше чем средний член команды. Я тоже пришёл к этому выводу. Я чувствую себя немножечко виноватым когда вижу какими чрезвычайно занятыми выглядят все остальные, а мне удаётся достичь лишь двух или трёх часов качественной работы в день при том, что я всегда был одним из самых производительных членов команды.
Но меня выводят из себя не те дни, когда мне удаётся достичь "всего лишь" двух действительно рабочих часов в день. Меня выводят из себя те дни, когда я не могу сделать ничего.
Я много думал об этом. Я пытался вспомнить время когда я выполнял больше всего работы в моей карьере. Вероятнее всего это произошло когда Microsoft перевёл меня в великолепный роскошный новый офис с большими окнами выходящими в прелестный каменный внутренний двор наполненный цветущими вишнями. Всё было просто супер. Месяцами я работал без остановок, прорабатывая в деталях спецификацию Excel Basic - монументальную стопку бумаги, вдающуюся в невероятные подробности, описывающую гигантскую объектную модель и среду программирования. Я буквально ни на секунду не останавливался. Когда я был вынужден ехать в Бостон на выставку MacWorld, я взял ноутбук с собой и документировал класс Window сидя на милой террасе Harvard Business School.
Как только вы попали в поток, несложно продлить это состояние. Многие мои дни проходят примерно так: 1) прийти на работу; 2) проверить почту, полазить по сети и т.д.; 3) решить что я мог бы пообедать прежде чем начать работать; 4) вернуться с обеда; 5) проверить почту, полазить по сети и т.д.; 6) окончательно решить что пора взяться за работу; 7) проверить почту, полазить по сети и т.д.; 8) опять решить что, действительно пора поработать; 9) запустить чёртов редактор; и 10) безостановочно писать код, пока я не осознаю что уже полвосьмого.
Где-то между пунктами 8 и 9 кажется есть дефект, потому что я не всегда могу преодолеть этот промежуток.
Возможно, это и есть ключ к производительности: всего лишь начать что-то делать. Возможно, работает именно потому, что когда вы начинаете парное программирование со своим коллегой, вы вынуждаете друг друга начать что-то делать.
Когда я был израильским десантником, один генерал заглянул к нам чтобы произнести небольшую речь о стратегии. В пехотных сражениях, говорил он, существует лишь одна стратегия: огонь и движение. Вы движетесь в сторону врага, одновременно ведя огонь. Ваши пули вынуждают его залечь, и в это время он не может стрелять в вас. (Это именно то, что солдаты имеют в виду когда кричат: "Прикрой меня". Это означает: "Стреляй в наших врагов, так чтобы они были вынуждены нагнуться и не могли стрелять в меня пока я перебегаю через эту улицу". И это работает.) Движение позволяет вам завоевывать территорию и приблизиться к врагу, где ваши пули достигнут своей цели с большей вероятностью. Если же вы не движетесь, враг начинает понимать что происходит - и это плохо для вас. Если вы не ведёте огонь, враг ведёт огонь по вам, вынуждая вас залечь.
Я запомнил это надолго. Я замечал, что почти любая военная стратегия, начиная с воздушных боёв и заканчивая масштабными манёврами военно-морского флота, основана на идее "огня и движения". Мне потребовалось ещё пятнадцать лет чтобы понять, что принцип "огонь и движение" действует и в обычной жизни. Необходимо ежедневно продвигаться вперёд, хотя бы на немного. Не имеет никакого значения что ваш код уродлив и содержит много ошибок, и никому он не нравится. Если при этом вы двигаетесь вперёд, - пишете код и постоянно исправляете ошибки - время на вашей стороне. Будьте начеку когда конкуренты ведут по вам огонь. Может они всего лишь хотят вынудить вас тратить всё ваше время отвечая на их залпы, так чтобы вы не могли продвигаться вперёд?!
Подумайте об истории всевозможных стратегий доступа к данным, разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые! Может это было вызвано технологической необходимостью? Может это результат некомпетентной группы проектирования, которой необходимо придумывать по-новой доступ к данным каждый чертов год? (Возможно, это в самом деле так.) Но конечный результат - всего лишь огонь для прикрытия. Конкуренты не имеют никакого другого выбора, кроме как тратить своё время, переписывая код под новые библиотеки и поспевая за лидером - время, которое они не могут использовать для создания новых возможностей. Посмотрите получше на ландшафт индустрии программного обеспечения. Компании, которые можно назвать успешными - это те, кто меньше всего зависят от монстров рынка программного обеспечения и не вынуждены тратить всё своё время догоняя лидеров, переписывая код и исправляя ошибки, возникающие только в Windows XP. Менее успешные компании - это те, кто тратит слишком много времени ловя каждое движение Microsoft, гадая в каком направлении она пойдёт дальше. Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет. Таковы правила игры, дружок. Вы собираетесь поддержать ? ? ? Вы поддерживаете всё это потому, что это нужно вашим клиентам, или потому что кто-то ведёт по вам огонь и вы чувствуете себя обязанным отвечать? Отделы по продажам крупных компаний понимают стратегию огня для прикрытия. Они приходят к своим клиентам и говорят: "ОК, вы не обязаны покупать именно у нас. Покупайте у самого лучшего продавца. Но убедитесь, что получите продукт, который поддерживает (XML / SOAP / CDE / J2EE), потому что иначе вы окажетесь ". Затем, когда небольшие компании пытаются продавать свои продукты на данном рынке, всё что они слышат - послушное повторение главным менеджером по технологиям: "У вас есть J2EE?". И им приходится тратить всё их время, переходя на J2EE, даже если это не увеличивает продаж и не даёт никакой возможности выделиться. Эта возможность - чисто для галочки. Вы её реализуете лишь потому, что вам необходима галочка, говорящая, что вы имеете данную возможность, но никто не будет её использовать и никому она по большому счёту не нужна. Это огонь для прикрытия.
"Огонь и движение" для маленьких компаний, типа моей, означает две вещи. Вы должны иметь и вам необходимо продвигаться вперёд каждый день. Рано или поздно вы выиграете. Всё, что я сумел сделать вчера - немного улучшить цветовую схему в FogBUGZ. Это нормально. Она становится лучше с каждым разом. Каждый день наша программа становится лучше и лучше и у нас всё больше и больше клиентов. И это единственное, что имеет значение. Пока наша компания не достигла размеров Oracle, мы не должны думать о грандиозных стратегиях. Мы должны просто приходить каждое утро и, как-нибудь, запускать редактор.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
о стратегии IV: Раздутое ПО
Переводчик: Дмитрий Майоров
Редактор: Сергей Петренко
23 марта 2001 г.
Пятая версия флагмана Microsoft - электронных таблиц Excel вышла в 1993 году. Она была положительно громадной: ей требовалось целых 15 мегабайт на диске. В те времена мы ещё помнили 20-мегабайтные диски первых PC (появившиеся примерно в 1985 году), и 15 мегабайт - это было много.
К моменту выхода версии Excel 2000 размер программы увеличился до 146 мегабайт... почти на порядок! Ох уж эти неумелые микрософтовские программисты, правда?
Неправда.
Готов поспорить, что вы думаете, что я собираюсь написать еще одну скучную статью, критикующую непомерно раздутое программное обеспечение, то, что принято называть bloatware. Ой-ёй-ёй, всё стало такое неподъёмное, жуть, edlin и vi гораздо лучше, чем Word и Emacs, мал, да удал, и т.д. и т.п.
Ха-ха! Я вас разыграл! Я не собираюсь писать очередную такую статью, потому что это неправда.
В 1993 году, считая в ценах того времени, место на жёстком диске, которое занимал Microsoft Excel 5.0, стоило примерно 36 долларов.
В 2000 году, считая по ценам 2000-го года, Microsoft Excel 2000 занимал места на один доллар и три цента.
(Эти числа приведены с учетом инфляции и основаны на информации о ценах на жёсткие диски, опубликованной ).
На самом деле, похоже на то, что Excel становится меньше!
Что же имеется в виду под "раздутым программным обеспечением" (английский термин bloatware)? даёт такое определение: "программное обеспечение, которое предоставляют минимальную функциональность и при этом требует для работы непропорционально большое количество дискового пространства и оперативной памяти. Термин часто используется в отношении приложений и обновлений операционных систем. Очень часто используется в мире Windows/NT, откуда и происходит."
Мне кажется, эти ребята просто ненавидят Windows. Не помню, чтобы за последние десять лет (с момента появления в 1989 году виртуальной памяти в Windows 386) я когда-либо сталкивался с нехваткой памяти. Цена дискового пространства упала до 0,0071 доллар за мегабайт и продолжает двигаться, как овца, решившая прыгнуть с дерева, чтобы научиться летать.
Возможно, это сможет объяснить Линус Экерлунд (Linus Еkerlund). На своей Веб-странице он , что "большой недостаток таких раздутых программ заключается в том, то их приходится загружать целиком, даже если требуется выполнить всего одно простое действие. Эти программы сжирают всю память... система используется неэффективно. Вы уменьшаете этим эффективность системы, что абсолютно не надо делать ."
Ох... Это съест всю мою память, ага. На самом деле, это неправда. Еще со времен Windows 1.0, с 1987 года, операционная система загружает страницы в оперативную память только тогда, когда они необходимы. Если исполняемый файл имеет размер в 15 мегабайт, а вы используете в нем код, занимающий только 2 мегабайта, то операционная система загрузит только эти 2 мегабайта. Фактически, в последних версиях Windows, операционная система автоматически переставит страницы на диске так, чтобы они шли подряд, чтобы ускорить последующие запуски.
И вряд ли кто-либо возьмётся отрицать, что в сегодняшних сверхмощных и очень дешевых компьютерах громадные современные программы запускаются всё равно быстрее, чем старые маленькие программы даже пять лет назад. Так в чём тогда проблема?
Подсказку даёт . Похоже, он потратил много часов на разбор небольшой утилиты от Microsoft, по-видимому будучи разозлён её размером в целый мегабайт (цена такого количества дискового пространства на момент написания статьи: 3,15 цента). По его мнению, программа должна была быть на 95% меньше. Фокус заключается в том, что утилита, которую он разбирает, - это нечто под названием RegClean, о которой вы вряд ли слышали. Эта программа проходит по реестру Windows, определяя неиспользуемые записи и удаляя их. Чтобы всерьез беспокоиться об очистке реестра Windows, вы должны быть немного одержимы этим. Так что я начинаю подозревать, что весь этот трёп про раздутые программы имеет больше отношения к , чем к программному обеспечению.
Фактически, есть куча причин для возникновения раздутых программ. Например, если программистам не надо заботиться о размере конечного продукта, они могут закончить разработку быстрее. А это, в свою очередь, означает, что пользователи получат больше возможностей, которые улучшают жизнь тем, кто их использует, и обычно не мешают остальным. Если производитель программного обеспечения остановится и начнет в течение двух месяц вычищать код, чтобы ужать продукт в два раза, польза от этого будет, скорее всего, незаметна. Может быть, если ваш диск постоянно набит под завязку, туда влезет еще один MP3 файл группы Duran Duran. А вот потери пользователей от ожидания новой версии в течении двух месяцев как раз ощутимы, и потери производителя от задержки продаж тем более.
Многие разработчики программного обеспечения попадаются на старое, как мир, правило "80/20". Кажется совершенно очевидным, что 80% людей используют лишь 20% возможностей программ. И вы убеждаете себя, что вам надо внедрить только 20% возможностей, и вы все равно сможете при этом продать 80% копий.
К сожалению, это не всегда одни и те же 20%. Каждый использует разные вещи. За последние 10 лет я слышал о десятках компаний, которые, решив не учиться на чужих ошибках, пытались выпускать "облегчённые" текстовые редакторы, в которых реализовано только 20% функций. Эта такая же старая история, как сам PC. В большинстве случаев дальше происходит следующее: фирма-производитель посылает копию своего нового текстового редактора журналисту для того, чтобы он написал о нем статью. Журналист пишет эту статью, используя этот новый текстовый редактор, и, закончив её, пытается найти функцию "Подсчет количества слов", которая им необходима, поскольку у большинство журналистов есть вполне четкие требования к объему статей. И, конечно, такой возможности нет, потому что она как раз попала в те "80%, которые никто не использует", и журналист в итоге , что облегчённые программы - это хорошо, раздутые программы - это плохо, но вот с этой чертовой штукой я работать не могу, потому что она не будет считать мои слова. Если бы мне платили доллар , когда такая история повторяется, я бы был очень счастлив.
Когда вы начинаете продавать свой "облегчённый" продукт и говорите "Эй, она весит всего мегабайт", людям это начинает нравиться, потом они спрашивают, есть ли в ней их наиважнейшая возможность, и разумеется, ее там нет, так что ваш продукт они не покупают.
Подведем итог: если ваша стратегия "80/20", у вас будут проблемы с продажами. Это реальность. Такая стратегия стара, как сама индустрия программного обеспечения, и она просто не окупается; что действительно удивительно так это то, сколько менеджеров думают, что она сработает.
Джеми Завински (Jamie Zawinski) сформулировал это лучше всех при первой версии Netscape, которая изменила мир. "Хотя это и было бы удобно, но Mozilla [Netscape 1.0] была такой большой не потому, что в неё напихано много всякого ненужного хлама. Mozilla большая потому, что ваши требования велики. Ваши требования велики потому, что интернет большой. Есть куча маленьких, стройных браузеров, которые, по случайному совпадению, не делают почти ничего полезного. Но совершенство бриллианта не было нашей целью при работе над Mozilla."
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Пять миров
Автор: Joel Spolsky
Переводчик: Максим Михальчук
Редактор: Евгений Дурцев, Мария Казачкова
понедельник, 6 мая 2002г
Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга..
Вы - разработчик программного обеспечения. Я тоже. Но у нас могут быть совсем неодинаковые цели и требования. На самом деле, существует несколько различных миров разработки ПО, и к разным мирам применимы разные правила.
Допустим, Вы читаете книжку по UML моделированию, а в ней нигде не говорится о её бессмысленности для программирования драйверов. Или же Вы читаете статью, утверждающую, что "20МБ среда [требующаяся для .NET] - это ", а она не содержит очевидного: если Вы пытаетесь написать код для пейджера с 32КБ ROM, то это ещё та проблема!
Я считаю, что в программировании есть пять миров, иногда пересекающихся друг с другом, а в основном нет. Это:
Ширпотреб
Внутреннее ПО
Встроенное ПО
Игры
Одноразовое ПО
При чтении одной из последних книг по Экстремальному программированию, одной из замечательных книг Стива МакКонннелла, сайта "Джоэль о софте" или журнала " Вы видите много утверждений, как же разрабатывать ПО, однако вряд ли Вы когда-либо замечали малейшее упоминание, о каком же всё-таки типе разработки они ведут речь, что довольно-таки плохо, ведь иногда в разных мирах необходимо разрабатывать по-разному.
Давайте кратко пройдёмся по этим категориям.
Ширпотреб - это ПО, которое должно "серьёзно" использоваться многими людьми. Оно может быть обёрнуто в целлофан и продаваться в сети компьютерных магазинов, или скачиваться по Интернет. Оно может быть коммерческим, шароварным, с открытым исходным кодом, под лицензией GNU или любым другим - главное в том, что такое ПО будет установлено и будет использоваться тысячами или миллионами людей.
Разработка ширпотреба сталкивается со своими проблемами из-за его особенных свойств:
Из-за большого количества пользователей, у которых часто есть альтернативное ПО, пользовательский интерфейс должен быть проще среднего, чтобы достичь успеха.
Так как оно запускается на таком множестве компьютеров, код должен быть необычайно эластичен к различиям между компьютерами. На прошлой неделе один из пользователей написал мне об ошибке в , которая проявляется только на польских Windows из-за того, как операционная система использует правый Alt для ввода специальных символов. Мы тестировали Windows 95, 95OSR2, 98, 98SE, Me, NT 4.0, 2000 и XP. Мы проводили тестирования с установленным IE 5.01, 5.5 или 6.0. Мы тестировали американские, испанские, французские, израильские и китайские версии Windows. Но мы не совсем ещё добрались до польских.
Существует три наибольшие вариации ширпотреба. ПО с открытым исходным кодом часто разрабатывается в условиях, когда за разработку никому не платят, что кардинально меняет его динамику. Например, вещи, не считающиеся "прикольными", обычно не реализовываются командой добровольцев и, как Метью Томас, это может повредить юзабилити. Разработка обычно географически рассредоточена, что выливается в абсолютно другое качество командного общения. В мире открытых исходников редко происходят личные встречи вокруг досок с прямоугольниками и стрелочками, поэтому те решения по дизайну, которые выигрывают от рисования, обычно плохо решаются в подобных проектах. Как результат, географически рассредоточенные команды намного лучше преуспели в клонировании существующего ПО, для которого не требуется или требуется принимать очень мало решений по дизайну.
Консультационное ПО - это вариант ширпотреба, который требует так много настроек и установок, что для его установки нужна целая армия консультантов по с непомерными ценами. Пакеты CRM и CMS обычно попадают в данную категорию. Может возникнуть ощущение, что эти пакеты на самом деле совсем ничего не делают, а лишь являются предлогом для прибытия армии консультантов по $300 в час. Хоть консультационное ПО и притворяется ширпотребом, высокая стоимость реализации означает, что оно больше похоже на внутреннее.
Коммерческое веб-ПО, такое как Salesforce.com или даже более тепличный вариант eBay всё равно должно быть простым в использовании и выполняться на множестве браузеров. Хотя у разработчиков есть роскошь (по крайней мере) некоторого контроля над средой "развёртывания" - компьютерами в информационном центре - им необходимо иметь дело с большим разнообразием веб-браузеров и большим количеством пользователей, поэтому я считаю данное ПО вариацией ширпотреба.
Внутреннее ПО должно лишь работать в одной ситуации на компьютерах одной компании, что делает его разработку намного проще. Вы можете сделать множество предположений о среде, в которой оно будет идти. Вы можете потребовать определённую версию Internet Explorer, Microsoft Office или Windows. Если нужен график, пусть за Вас его построит Excel; у всех в нашем отделе есть Excel (но только попробуйте такое с ширпотребом и вы уже устранили половину своих потенциальных покупателей).
Юзабилити здесь не так важно, ведь программным обеспечением необходимо будет пользоваться небольшому количеству людей, да и у них по существу нет никакого выбора, так что им придётся как-то уж с ним уживаться. Скорость разработки более важна. Так как вся стоимость разработки ложится всего лишь на одну компанию, количество обоснованно выделенных ресурсов на разработку значительно меньше. Microsoft может себе позволить потратить $500,000,000 на разработку операционной системы, которая обойдётся среднему пользователю примерно в $80. Но когда Detroit Edison разрабатывает платформу для торговли электроэнергией, размер инвестиции должен иметь смысл для одной компании. Для получения приемлемой окупаемости нельзя тратить столько же, сколько и на ширпотреб. Поэтому увы, но большинство внутреннего ПО просто вызывает отвращение.
Встроенное ПО имеет то уникальное свойство, что оно идёт вместе с куском железа, и в большинстве случаев не может быть обновлено. Это совсем другой мир, скажу я Вам. Требования к качеству намного выше, ведь другого шанса не будет. Возможно, придётся иметь дело с процессором намного более медленным, чем типичный процессор персоналки, поэтому код придётся долго оптимизировать. Быстрый код важнее красивого кода. Доступные устройства ввода-вывода могут быть очень ограничены. У системы глобальной навигации в машине, которую я на прошлой неделе взял напрокат, был настолько жалкий интерфейс, что её использование нагоняло смертельную тоску. Вы никогда не пробовали вводить в одну из таких штуковин адрес? Они показывают на экране "клавиатуру" и вы должны выбирать буквы из 5 матриц по (другие примеры этого интерфейса расположены по данной ссылке. У системы глобальной навигации в моей собственной машине экран реагирует на нажатия, что поразительно улучшает интерфейс. Однако, я отвлёкся).
Игры уникальны по двум причинам. Во-первых, экономика разработки игр ориентирована на хиты. Некоторые игры становятся хитами, но намного больше игр проваливаются, поэтому если Вы хотите делать деньги на разработке игр, это необходимо понять и иметь портфолио игр, так чтобы хит-блокбастер покрывал расходы провалов. Это больше похоже на кино, чем на программное обеспечение.
Ещё большей проблемой при разработке игр является наличие всего одной версии. Как только Ваши пользователи прошли Duke Nukem 3D, они не будут обновляться до Duke Nukem 3.1D только ради исправления нескольких ошибок и нового оружия. За некоторым исключением после прохождения игры до конца, опять в неё играть довольно скучно. Поэтому у игр такие же требования к качеству, как и у встроенного ПО, и существует невероятный финансовый императив правильно сделать всё с первого раза. Разработчики ширпотреба могут позволить себе роскошь знания, что если версия 1.0 не удовлетворяет желания пользователей и не продаётся, то, возможно, версия 2.0 будет.
И, наконец, Одноразовый код, который создаётся на время исключительно с целью получения чего-либо ещё, что никогда более не понадобится. К примеру, маленький скрипт, перемалывающий полученный входной файл в какой-нибудь другой формат, нужный всего один раз.
Есть, наверное, и другие типы разработки программ, которые я уже забыл.
Важно знать, что когда бы Вы ни читали книгу о методологии программирования, написанную гуру/консультантом по разработке ПО, работающим на полную ставку, можете быть спокойны, что он говорит о разработке внутреннего, корпоративного ПО. Не ширпотребного, не встроенного и, конечно же, не игр. Почему? Потому что именно корпорации нанимают этих гуру. Они им платят. (Поверьте мне, id software никогда и ни за что не собирается нанимать Эда Йордона, чтобы тот размышлял о структурном анализе.)
На прошлой неделе Кент Бэк заявил, что системы отслеживания ошибок не нужны при экстремальном программировании, потому что комбинация парного программирования (с постоянной проверкой кода) и разработка, основанная на тестах (гарантирующая 100% покрытия кода автоматическими тестами) означает, что у Вас вряд ли когда-либо будут ошибки. Это показалось мне неправильным. Я заглянул в нашу собственную , чтобы проверить, каких типов ошибок в ней особенно много.
Имеющий глаза да увидит – я обнаружил, что очень мало тамошних ошибок могли бы быть обнаружены парным программированием или тестами. Многие наши "ошибки" на языке экстремального программирования называются историями – по существу, это лишь запросы о возможных улучшениях. Мы используем систему отслеживания ошибок для запоминания, выставления приоритетов и управления всеми маленькими улучшениями и большими возможностями, которые мы хотели бы реализовать.
Много других ошибок были обнаружены только лишь после длительного использования на месте. Проблема с польской клавиатурой. Нет способа, которым парное программирование поможет найти такие вот ошибки. Ещё есть логические ошибки использования различных возможностей, которые никогда с нами не случались. Чем больше и сложнее программа, тем больше взаимодействий между возможностями, о которых Вы и не догадываетесь. Определённая последовательность символов ({${?, если хотите знать) вводит в замешательство лексер. Некоторые ftp-сервера сообщают об ошибке при попытке удаления несуществующего файла (наш на такое не жалуется, поэтому такого никогда с нами не случалось).
Я внимательно изучил каждую ошибку. Из 106 ошибок, которые мы исправили в первом пакете обновления для CityDesk, ровно 5 могли бы быть предотвращены с помощью парного программирования или разработки на основе тестов. У нас на самом деле было больше ошибок, о которых мы уже знали, но не считали их важными (только если нас не поправят наши покупатели!), чем ошибок, которые могли бы быть выловлены методами ХР.
Но Кен прав, только вот для других типов разработки. Для большинства корпоративных приложений ни одна из рассмотренных выше не считалась бы ошибкой. Программа вылетает от неверного ввода? Запустите ещё раз, и на этот раз следите за своими {${?! И мы используем только лишь один FTP-сервер и никто во всей компании не использует Польские Windows.
Большей частью разработка ПО одинакова вне зависимости от проекта, но не вся. Когда Вам говорят о методологии, подумайте о том, как она согласуется с делаемой именно Вами работой. Подумайте, откуда говорящий. Стив МакКоннелл, Стив Магуайр и я все из одной песочницы: мира ширпотребных электронных таблиц, написанных в Редмонде, штат Вашингтон. И у таких у нас высокая планка на лёгкость в использовании и низкая для ошибок. Большинство других гуру методологии зарабатывают свой кусок хлеба, консультируя внутренние корпоративные разработки, поэтому о них они и говорят. В любом случае, мы должны уметь учиться друг у друга.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Пять (неуважительных) причин не иметь тестеров
Автор: Джоэл Сполски
Переводчик: Алексей Боленок
30 апреля 2000 года
В 1992 году ошибки в программном обеспечении сильно беспокоили некоего Джеймса Гляйка (James Gleick), автора научных трудов. Гляйк счёл ужасной как раз вышедшую к тому времени новую версию Microsoft Word for Windows. Он отправил в «Сандей Нью-Йорк Таймс Мэгэзин» , в которой высмеял коллектив разработчиков Word за их невосприимчивость к чаяниям клиентов и за выпуск крайне неотлаженного продукта.
Немного позднее, пользуясь услугами местного Интернет-провайдера Panix (чьими услугами, кстати, пользуюсь и я), он захотел найти способ автоматически сортировать и фильтровать свою почту. В UNIX для этого есть шаманская утилита, которая называется procmail. Её интерфейс несколько… скажем так, невразумителен. С этим соглашаются даже самые убеждённые фанаты UNIX.
Короче, мистер Гляйк нечаянно сделал невинную опечатку в procmail или что-то в этом духе. В общем, вся его почта удалилась. Со злости он решил, что создаст собственную компанию, предоставляющую доступ в Интернет. Он нанял программиста Юдея Айвечури (Uday Ivatury) и создал компанию Pipeline, действительно опередившую своё время: это был первый коммерческий Интернет-провайдер, предоставлявший хоть какой-то графический интерфейс.
Конечно же, у Pipeline тоже были проблемы. В самой первой версии не было никакого протокола коррекции, что довольно часто приводило к искажениям при передаче данных — вплоть до того, что возникали аварийные ситуации. В их программах, как и в любых других, были ошибки. И я, когда в 1993 году устраивался на работу в Pipeline, на собеседовании поинтересовался мнением мистера Гляйка о написанной им ранее статье. «Теперь, когда вы находитесь по другую сторону баррикад», спросил я, — «вы стали хоть немного понимать, как трудно создавать хорошее программное обеспечение?»
Но Гляйк не раскаялся. Он отрицал, что в Pipeline были ошибки. Он отрицал, что его программа была ничем не лучше Word. И он сказал мне: «Когда-нибудь и ты, Джоэл, начнёшь ненавидеть Microsoft». Меня поразило то, что, несмотря на годовой опыт разработки — не использования, а именно разработки программного обеспечения, — он ни капельки не понял, как же сложно сделать действительно надёжный и простой в использовании продукт. Поэтому я и сбежал оттуда, отклонив предложение устроиться на работу. А Pipeline впоследствии была куплена компанией PSI, самым странным Интернет-провайдером в мире, а затем была без церемоний поставлена к стенке и расстреляна.
В любом программном обеспечении есть ошибки. Дело в том, что процессоры крайне педантичны. Они совершенно по-детски отказываются работать с чем-либо, что не разжевали для них тщательнейшим образом. Когда мой ноутбук находится вне дома, он постоянно глючит, потому что не может найти сетевой принтер, к которому привык. Дитё малое. Причём проблема, скорее всего, кроется в одной-единственной строчке кода, в которой допущена копеечная и практически ничего не значащая ошибка.
Вот почему вам решительно необходимо иметь отдел технического контроля (ОТК). Вам понадобится один тестер на каждых двух программистов (а если ваше программное обеспечение должно работать с множеством различных настроек или на разных операционных системах, то и больше). Каждый программист должен плотно работать с одним тестером, предоставляя ему частную сборку настолько часто, насколько это необходимо.
ОТК должен быть независимым и могущественным. Он не должен отчитываться перед отделом разработки. В идеале, начальник ОТК должен иметь право вето на выпуск продукта, который не прошёл успешного освидетельствования.
Первую настоящую работу в индустрии программного обеспечения я получил в компании Microsoft. Она не сказать, чтобы славилась высоким качеством своего кода, но всё же там работало довольно много тестеров программного обеспечения. Поэтому я предполагал, что разработка программного обеспечения никогда не обходится без тестирования.
Зачастую это действительно так. Но просто поразительно, у скольких компаний нет тестеров. На самом деле, многие команды программистов даже и не верят в тестирование.
Казалось бы — после мании Качества с заглавной буквы, охватившей мир в 80-х годах, после всех этих бессмысленных международных сертификатов типа ISO-9000 и моды на словечки типа «шесть сигм», менеджеры должны были бы уже понять, что выпуск высококачественных продуктов с деловой точки зрения не так уж и бессмыслен. Кстати, они, в общем-то, это понимают. Большинству из них удалось осознать это — головой. Однако они всё ещё находят множество причин отказаться от тестирования программного обеспечения. Притом все эти причины неуважительны.
Я надеюсь, что смогу объяснить вам, почему же они неуважительны. Но если вы торопитесь, то пропустите остаток этой статьи. Просто ступайте и наймите на полный рабочий день одного тестера на каждых двух программистов.
Итак, вот самые распространённые плачи вавилонские на тему того, почему не надо нанимать тестеров:
Ошибки возникают из-за лени программистов.
«Если мы наймём тестеров», говорится в этой небылице далее, — «то программисты станут работать небрежно и начнут писать глючный код. С помощью отказа от тестирования мы сможем заставить программистов с самого начала писать код правильно».
Хрен. Если вы так думаете, значит, вы либо никогда не писали кода, либо обманываетесь насчёт того, как это делается. Глюки, по определению, вылезают потому, что программисты не заметили их в своём собственном коде. А ведь во многих случаях, чтобы просто заметить ошибку, никак не обойтись без второй пары глаз.
Когда я писал код в фирме Juno, я всё время наступал на одни и те же грабли. Я, по свойственной мне привычке, во многом полагался на мышь. Но у нашей потрясающей, просто-таки сверхъестественной тестерши были немного другие привычки: она чаще пользовалась клавиатурой (и при этом, как ни странно, не забывала тщательно проверять все возможные устройства пользовательского ввода на предмет корректной работы с интерфейсом). Она быстро обнаружила целую пропасть ошибок. Иногда она заявляла мне, что интерфейс вообще не работает, просто-таки на все 100%, хотя у меня он всегда работал замечательно. Но когда она при мне воспроизводила ошибку, мне хотелось стукнуть себя по лбу. Клавиша Alt! Так вот оно что, ты нажимала клавишу Alt! И как же это я не проверил?
Моё программное обеспечение лежит в сети. Я могу исправить ошибки в течение секунды.
Ха-ха-ха-ха-ха! Ну ладно, положим, это действительно так, сеть даёт возможность распространять баг-фиксы гораздо быстрее, чем раньше, во времена коробочных продуктов. Но не следует занижать стоимость исправления ошибки, даже на веб-сайте, после того, как проект уже был заморожен. Начнём с того, что, исправив одну ошибку, вы можете наплодить ещё больше. Но гораздо хуже вот что: если вы окинете взглядом весь процесс, вам станет ясно, что выкладывание исправлений может оказаться довольно дорогой альтернативой выкладыванию новых версий. Помимо этого, вы произведёте плохое впечатление. Это описано в следующем пункте:
Мои пользователи протестируют программное обеспечение за меня.
Ага, страшная и ужасная «Защита Netscape». Эта несчастная компания нанесла сокрушительный урон своей репутации следующей методологией «тестирования»:
Когда у программистов всё готово наполовину, выложить неотлаженную программу в сеть. Когда программисты говорят, что у них готово всё, выложить неотлаженную программу в сеть. Повторить шесть-семь раз. Назвать одну из версий «окончательной». Выпускать релизы .01, .02, .03 каждый раз, когда на c|net упомянут об очередной позорной ошибке.
Эта компания была первопроходцем в использовании идеи «широкого распространения бета-версий». В буквальном смысле этого слова миллионы пользователей скачали незаконченные и неотлаженные релизы. В течение первых нескольких лет практически у всех пользователей Netscape стоял какой-нибудь предварительный релиз или бета-версия. И, хотя окончательный релиз обычно был достаточно стабилен, всегда существовала такая туева хуча людей, пользующихся промежуточными версиями Netscape, что общее впечатление о программе было достаточно скверным.
Кроме того, самая суть тестирования «вашими пользователями» состоит в том, что они находят ошибки, а вы их исправляете. К сожалению, ни Netscape, ни какая-либо другая компания в мире не обладает людскими ресурсами, достаточными, чтобы разгрести 2 000 000 отчётов об ошибках от пользователей и решить, какие из этих ошибок по-настоящему важны. Когда я посылал отчёты об ошибках в Netscape 2.0, то их сайт постоянно падал и просто-напросто не давал мне отправить отчёт (который, конечно же, всё равно канул бы в Лету). Но Netscape ничему не учится. Тестеры текущей «ознакомительной» версии, 6.0, жалуются в новостях, что сайт по-прежнему не даёт посылать отчёты. Годы спустя! Всё та же проблема!
Готов спорить, что почти все из мириад отчётов так или иначе касались 5 или 10 действительно очевидных ошибок. И в этих стогах сена похоронены одна или две интересных, трудноуловимых ошибки, о которых кто-то дал себе труд сообщить. Но, так как на эти отчёты всё равно никто не смотрит, ошибки потерялись.
Самое плохое в таком способе тестирования то, что о вашей компании составляется в высшей степени отвратительное впечатление. Когда фирма Userland выпустила первую версию своего ведущего продукта Frontier for Windows, я скачал её и начал прорабатывать учебное пособие. К сожалению, Frontier несколько раз упал. Я дословно выполнял все инструкции в том же порядке, в котором они были напечатаны в учебном пособии, но я не смог проработать с программой более двух минут. У меня создалось впечатление, что никто в Userland не озаботился даже минимальным объёмом тестирования, чтобы убедиться, что хотя бы учебное пособие работает. Плохо понятно, как вообще применять к такому продукту слово «качество». Это-то и отворотило меня от Frontier на очень долгое время.
Ни один хороший тестер не хочет работать тестером.
Вот это — действительно серьёзная проблема. Очень сложно найти хорошего тестера.
Среди тестеров, как и среди программистов, лучшие на порядок лучше средних. В Juno у нас была одна тестерша, Джил Макферлейн (Jill McFarlane), которая находила в три раза больше ошибок, чем все четверо других тестеров, вместе взятых. Я не преувеличиваю. Я это действительно измерял. Она была в двенадцать раз полезнее среднего тестера. Когда она уволилась, я послал нашему директору электронное письмо следующего содержания: «Я бы лучше взял одну Джил работать по понедельникам и вторникам, чем остальных сотрудников ОТК, вместе взятых, на полную неделю».
Всё, что можно сделать с этой проблемой — это признать, что она существует, и решать её. Вот несколько предложений:
Используйте тестирование как следующую после отдела техподдержки ступень карьерной лестницы. При всей нудности тестирования, оно гораздо лучше телефонного общения с разгневанными пользователями. Это может послужить способом приостановить текучку в отделе техподдержки. Позволяйте тестерам повышать свою квалификацию на курсах программирования, и поощряйте самых умных к разработке автоматизированных комплексов тестирования при помощи программных инструментов и сценарных языков. Это гораздо интереснее, чем снова, и снова, и снова тестировать один и тот же диалог. Осознайте, что среди лучших тестеров будет большая текучка. Активно нанимайте народ, чтобы добиться постоянного притока людей. Не останавливайте приём на работу только потому, что у вас кончились строчки в зарплатной ведомости. Не всё коту масленица, придёт Великий Пост. Ищите «нетрадиционных» сотрудников — сообразительных подростков, студентов, пенсионеров, работающих на полставки. Вы можете создать великолепный отдел тестирования из двух-трёх высококлассных профессионалов, работающих на полную ставку, и ватаги парнишек из Бронкс-Сайенс (сильнейшего вуза Нью-Йорка), работающих за оплату учёбы. Нанимайте временных сотрудников. Если вы наймёте 10 временных сотрудников, чтобы они пришли и повозились с вашим продуктом в течение нескольких дней, вы найдёте жуткое количество ошибок. Скорее всего, у двух или трёх из этих работников обнаружатся хорошие задатки тестеров, и в этом случае имеет смысл выкупить их контракт и взять их на постоянную работу. Заранее отдавайте себе отчёт, что некоторые из временных сотрудников будут бесполезны в качестве тестеров; распустите их по домам и двигайтесь дальше. Как раз для этого и нужны кадровые агентства по найму временных сотрудников.
А вот как нельзя бороться с проблемой:
Даже и не думайте предлагать выпускникам колледжа по специальности «вычислительная техника» поработать у вас с тем условием, что «каждый должен пройти через тестирование прежде, чем приступить к написанию кода». Я такое видел, и не раз. Из программистов не получается хороших тестеров, и вы потеряете хорошего программиста, заменить которого — гораздо дороже.
И, наконец, причина номер один, по которой люди не нанимают тестеров:
Я не могу позволить себе держать тестеров!
Эта причина — самая глупая, и легче всего поддаётся развенчиванию.
Вне зависимости от того, как тяжело найти тестеров, они всё равно дешевле программистов. Намного дешевле. И если вы не нанимаете тестеров, то тестированием придётся заниматься программистам. И если вы думаете, что текучка среди тестеров — это плохо, подождите, и вы увидите, как дорого обойдётся замена гения-программиста ценою в 100 000 $ в год, которому надоест выслушивать пассажи типа «потрать несколько недель на проверку, и только после этого мы выпустим релиз», и который уйдёт в более профессиональную компанию. На одни только комиссионные, которые будут потрачены на поиск его замены, вы смогли бы целый год держать трёх тестеров.
Экономия на тестерах — нелепость настолько вопиющая, что просто диву даёшься, как много людей этого не понимают.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Планирование программного обеспечения малой кровью
Автор: Джоэл Сполски
Переводчик: Вадим Никитин
29 марта 2000
В прошедшем октябре, Северо-восточные США были обклеены объявлениями о некоем новом поезде-экспрессе называемом Acela, двигающимся от Бостона до Вашингтона. Можно было подумать, что такое количество рекламы на ТВ, объявлений и плакатов повсюду, создаст некоторый спрос на новую экспресс-службу Amtrak.
Возможно, –Amtrak-у так и не удалось выяснять это. Acela был отсрочен, и отсрочен снова, маркетинговая кампания прошла, а Acela так и не начал работать. Это напомнило мне другой случай: менеджер по маркетингу говорил, когда его изделие получило бредовый обзор за месяц до поступления в продажу: "Огромная реклама! Плохо, что Вы не можете купить чёртову вещь!"
Теперь, когда я это пишу, появился web браузер Netscape 5.0 почти с двухгодичным опозданием. От части, из-за их самоубийственной ошибки: они выбросили все свои исходные тексты и начали сначала. Та же ошибка что и обрёкшая Ashton-Tate, Lotus, и Apple MacOS стать хламом истории софта. Netscape увидели как распространение их браузера шагнуло от около 80% до около 20%, и всё это время они ни чем не могли ответить конкурентам, потому что их ключевой продукт был разобран на 1000 кусков, так что нельзя было выявить ни каких контуров (was disassembled in 1000 pieces on the floor and was in no shape to drive anywhere).
Это единственное плохое решение, более чем что-либо другое, было той ядерной бомбой которой Netscape сами себя сдули как ветром. (Jamie Zawinski - располагает подробностями).
И так, вы должны составить план. Это то, что не хочет делать почти ни один программист. Мой опыт показывает, что подавляющее большинство пытается вообще избежать составления плана. Из немногих составляющих план, большинство делают это равнодушно, только потому что босс их заставляет, и никто фактически не верит плану, за исключением высшего руководства, которое одновременно полагает, что "ни один программный проект ни когда не бывает вовремя" и что НЛО существуют.
Так, почему ни кто не составляет планов? Две ключевые причины. Первая - реальная боль (real pain). Вторая - ни кто не верит что это чего-нибудь стоит. Зачем связываться со всеми проблемами составления плана если он всё равно будет неправильным? Существует представление, что планы стабильно оказываются неверными и только делаются хуже по прошествию времени, так ради чего страдать?
Вот простой, безболезненный способ делать планы, которые являются фактически правильными.
1) Используйте Excel. Не используйте ни чего впечатляющего подобно Microsoft Project. Проблема в том что Microsoft Project предполагает будто вы желаете потратить много времени заботясь о зависимостях. Зависимость - это, когда у вас есть две задачи, одна из которых должна быть завершена до того как следующая cможет начаться. Я нахожу, что с программным обеспечением, зависимости настолько очевидны, что не стоит труда, формально следить за ними.
Другая проблема с Project в том, что он предполагает, будто вы захотите иметь возможность нажать маленькую кнопочку и "перебалансировать" весь план. Однозначно, он собирается переупорядочить элементы плана и переназначить элементы разным людям. Для программного обеспечения, это не имеет смысла. Программисты не взаимозаменяемы. Джону потребуется в семь раз больше времени, чтобы исправить ошибку Риты, чем Рите, чтобы исправить ошибку Риты.
И если Вы попробуете поместить вашего UI-программиста на WinSock-проблему, он остановится и потратит неделю чтобы достичь быстродействия WinSock-программиста. Суть в том, что Project разработан для постройки офисных построений, а не софтверных.
2) Упрощайте. Стандартный формат который я использую для планов так прост, что вы можете запомнить его. Начните только с семи столбцов:
3) Каждое свойство должно состоять из нескольких задач. Свойство, это нечто вроде добавления проверки орфографии к вашей программе. Добавление проверки орфографии состоит из нескольких совершенно отдельных задач, которые программист должен сделать. Наиболее важная часть создания плана, это составление списка задач. Таким образом кардинальное правило:
4) Только программист, который будет писать данный код, может распланировать его. Любая система, где начальство пишет план и вручает его программистам, обречена на неудачу. Только программист, который будет делать данную работу, способен определить, какие шаги нужно предпринять, чтобы реализовать данное свойство. И только программист сможет оценивать, сколько времени займёт каждый шаг.
5) Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях. (Когда я вижу план, измеряемый в днях, или даже в неделях, я знаю –он не реален). Возможно вы думаете, что план с мелко дроблёными задачами просто более точен. Неправильно! Очень сильно ошибаетесь! Когда вы начнете с плана с грубо определенными задачами и затем разобьёте его на меньшие задачи, вы увидите, что получили другой результат, не просто более точный. Это будет полностью другое число. Почему так получается?
Когда вы ставите мелко дроблёные задачи вы вынуждаете себя фактически вычислять то, какие шаги вы предпримите. Написать подпрограмму foo. Создать диалог такой и такой. Прочитать файл wawa. Эти шаги просто оценить, потому что прежде вы уже писали подпрограммы, создавали диалоги, и читали файлы wawa.
Если вы неаккуратны и ставите большие "короткие" задачи ("реализовать исправление грамматики"), то вы в действительности не думали, что вам предстоит сделать. Поскольку вы не думали, что собираетесь делать, вы просто не можете знать, сколько времени на это потребуется.
Как правило, каждая задача должна быть от 2 до 16 часов. Если у вас в плане стоит задача на 40 часов (одна неделя), значит вы не достаточно её разбили.
Имеется другая причина устанавливать мелкодроблёные задачи: это вынуждает вас разрабатывать проклятое свойство. Если у вас в программе будет некое сомнительное свойство, названное "Межсетевая Интеграция" и вы на него планируете недели, то вы обречены, приятель. Если же вам нужно определить, какие подпрограммы вы собираетесь написать, то вы вынуждены выявить свойство. Заставляя себя планировать вперед на этом уровне, вы устраняете много неустойчивости в программном проекте.
6) Отслеживайте начальную и текущую оценку. Когда вы впервые добавляете задачу в план, оцените, сколько она займёт в часах и поместите свою оценку в поля Нач [альная] и Тек [ущая] Оценка. По прошествию времени, если задача оказалась более долгой (или короткой) чем вы думали, вы можете изменить столбец Тек Оцн так как вам необходимо. Это лучший способ учиться на собственных ошибках и тренироваться, оценивать задачи точно. Большинство программистов не имеют понятия, как сделать предположение, относительно продолжительности дел. Это - нормально. Пока вы непрерывно изучаете и непрерывно модифицируете план, в процессе своего обучения, - план работает. (Возможно, вам придется исключить какое-либо свойство или устранить неточность [в оценке времени], но план по прежнему будет работать правильно, в том смысле, что будет постоянно сообщать вам, когда вам нужно удалить свойство или исправить неточность). Я обнаружил, что большинство программистов становятся очень хорошими планировщиками после приблизительно одного года опыта.
Когда задача выполнена, поля Тек Оцн и Прошло будут равны, а поле Осталось пересчитается в 0.
7) Обновляйте столбец Прошло каждый день. На самом деле вам не надо смотреть на секундомер, кода вы программируете. Перед самым вашим уходом домой, –или уходом ко сну за столом, если вы один из тех балбесов, симулирующих, что работают 8 часов (ха-ха!), - определите над какими задачами вы работали и раскидайте соответственно около 8 часов в столбце Прошло. Поле оставшегося времени Excel вычислит автоматически.
Заодно исправьте и колонку Тек Оцн для своих задач чтобы отразить новую действительность. Ежедневное модифицирование вашего плана отнимет у вас не более двух минут. Вот почему это безболезненный способ - он быстр и прост.
8) Добавьте строки для Праздников, Отпуска, и т.д. Если ваш план будет охватывать более года, каждый программист вероятно возьмёт 10 - 15 дней отпуска. Вам необходимо свойство в вашем плане называемое Выходные, одно для праздников, и что-то ещё для всего остального, что потребляет народное время. Идея состоит в том, что дата отгрузки может быть вычислена, делением на 40 суммы по столбцу оставшегося времени, получится - сколько осталось недель работы, включая полностью всё.
9) Поместите в план время отладки! Отладка самая трудная вещь для оценки. Вспомните последний проект, в котором вы принимали участие. Есть шанс, что отладка займёт от 100 до 200 % времени, которое потребует написание кода в первой редакции. Так что нужен строковый элемент в плане. И, вероятно, это будет самый большой строковый элемент.
Вот как это работает. Скажем, разработчик работает над wawa. Нач Оцн была 16 часов, но на данный момент затрачено 20 часов и, похоже, потребуется ещё дополнительно 10 часов работы. Так что разработчик вводит 30 под Тек Оцн и 20 под Прошло.
Неточности вероятно будут. (At the end of the milestone, all these "slips" have probably added up to quite a bit). Теоретически, чтобы компенсировать неточности и обеспечить своевременный выход продукта, мы должны исключить какие-нибудь свойства. Хорошо если первое свойство, которое мы сможем исключить, будет большое-пребольшое свойство называемое Буфер, под которое выделено много-премного часов.
В принципе, разработчики отлаживают код, в процессе написания. Программист не должен ни когда работать над новым кодом, если он может за место этого исправлять ошибки. Количество ошибок всегда должно оставаться на столько малым, на сколько это возможно, по двум причинам:
1) Проще устранить ошибки в тот же день, в который вы написали код. Это может оказаться очень трудным и долгим - исправлять ошибки месяцем позже, когда вы уже забудете, как в точности работает код.
2) Исправление ошибок - подобно научным исследованиям. Невозможно предугадать, когда вы совершите открытие и найдёте ошибку. Если имеются только одна или две не обработанных ошибки в любое заданное время, то будет просто оценить время выхода программы, потому что в вашем будущем не будет слишком много не поддающейся оценке науки. С другой стороны, если имеются сотни или тысячи ожидающих обработки ошибок, невозможно предсказать, когда все они будут исправлены.
Если разработчики всегда устраняют ошибки, по ходу своего продвижения вперёд, что за прикол в наличии строкового элемента для отладки? - Хорошо, даже если вы будете устранять каждую ошибку, по мере своего продвижения, в конце каждого этапа неизбежно будет куча работы над ошибками, когда тестеры (свои и бета) найдут по настоящему трудные ошибки.
10) Добавьте в план время на интеграцию. Если у вас больше одного программиста, неизбежно, возникнут вещи, которые они будут делать противоречиво, и эти противоречия должны быть разрешены. Они могут одновременно разрабатывать диалоговые окна для подобных задач, - это излишняя непоследовательность. Кто-то должен будет пройти через все меню, акселераторы клавиатуры, кнопки на панелях и т.д., приводя в порядок все новые элементы меню, которые народ вольно - невольно добавлял. Будут появляться ошибки компиляции, которые вылезают, как только два человека загрузят код в систему контроля версий. Это должно быть исправлено, и для этого нужен строковый элемент в плане.
11) Добавьте буфер в план. Вещи склонны ускользать. (Things tend to run over). Есть два важных вида буфера, которые вам могут понадобиться. Во-первых, буфер для учёта задач, занявших больше времени, чем было первоначально оценено. Во-вторых: буфер для учёта задач, о которых вы не знали, что вам придётся их делать, обычно потому, что начальство решило, что разработка wawa СУПЕР ВАЖНА и не может быть отложена до следующего выпуска.
Возможно, вы удивитесь, узнав, что праздники, отпуска, отладка, интеграция, и буферное время вносят больший вклад, [в общую длительность проекта] чем фактические задачи. Если это вас удивляет, значит, вы не участвовали в длительных проектах, не так ли? Опасно игнорировать это.
12) Никогда, не позволяйте менеджерам ни при каких обстоятельствах, указывать программистам, уменьшать оценку времени. Много начинающих программных менеджеров думают, что они могут "мотивировать" своих программистов, работать быстрее, давая им симпатичные, "плотненькие" (нереально короткие) планы. Я думаю, что этот вид мотивации - без мозгов (brain-dead). Когда я отстаю от плана, я чувствую себя обреченным, попадаю в депрессию, становлюсь неактивным. Когда я работаю с опережением плана, я весел и производителен. План - не место, для психологических игр.
Если ваш менеджер заставляет вас уменьшить оценку времени, есть что делать: Создайте новый столбец в плане, с именем Оценка Рика (предположим вас зовут Рик). Поместите туда свою оценку. Позвольте вашему менеджеру делать всё что угодно с колонкой Нач Оцн. Игнорируйте его оценку. Когда проект выполнен, посмотрите, кто был ближе к действительности. Я обнаружил, что стоит только пригрозить поступать так, как произойдут чудеса, особенно, когда ваш менеджер увидит, что он добился только того что попал на конкурс под названием "как медленно вы можете работать"!
Почему непутёвые менеджеры пытаются заставить программистов снижать оценки времени?
Когда проект начинается, технические менеджеры уходят, встречаются с деловыми людьми, и появляются со списком свойств, который, как они думают, займёт около 3-х месяцев, но в действительности он займёт 9. Когда вы думаете о написании кода без учёта всех шагов, которые предстоит сделать, всегда кажется, что потребуется n времени, хотя реально, скорее всего, потребуется 3n. Когда вы составляете реальный план, вы складываете все задачи и понимаете, что проект оказывается намного более длинный чем казалось сначала. Действительность погружается [куда-то] (Reality sinks in).
Непутёвые менеджеры пытаются ответить на это, прикидывая, как заставить людей, работать быстрее. Это не очень реально. Возможно вы способны нанять больше людей, но им нужно ещё выйти на заданную скорость, возможно они и станут работать на 50% эффективнее в течение нескольких месяцев (при этом понижая эффективность тех кто должен выполнять роль их наставников). Во всяком случае, на этом рынке, добавление хороших программистов может позволить уложиться в 6 месяцев.
Возможно, вы способны добиться от людей на 10% большего выхода исходных текстов, временно, той ценой, что вы заставите их сгореть на 100% за год. Не большой прирост, притом, что это напоминает поедание зерна предназначенного для посева.
Возможно вы способны добиться от людей на 20% большего выхода исходных текстов, прося каждого работать супер тяжело, независимо от того, насколько он устал. Ажиотаж, время отладки удвоится. Идиотский шаг который блестяще отзовется на [вашем] кармическом пути.
Но вы никогда не добьётесь 3n из n, ни при каких обстоятельствах, а если вы думаете, что добьётесь, пожалуйста пришлите мне по е-мэйл график биржевых котировок акций вашей компании, чтобы я мог сыграть на понижение (email me the stock ticker of your company so I can short it).
13) План подобен деревянным кубикам. Если у вас есть набор деревянных кубиков, и вы не можете уложить их в коробку, то у вас два варианта, или взять большую коробку, или удалите несколько кубиков. Если вы считали что сможете обеспечить выход в свет через 6 месяцев, но по плану получается 12, то вы оказываетесь перед необходимостью или задержать выход, или отобрать некоторые свойства которые придётся удалить. Однако вы не способны уменьшить кубики, и если вам кажется, что вы способны, значит вы просто лишаете себя полезной возможности реально смотреть в будущее, обманываете себя относительно того что вы там видите.
А вы знаете, это крутой побочный эффект - то, что вы будете вынуждены удалять свойства. Почему это хорошо? Предположим, что у вас есть два свойства: одно, которое является действительно полезным и сделает ваш продукт действительно крутым (например: таблицы в Netscape 2.0), и другое, которое является действительно простым, одним из таких которые программисты любят реализовывать (например: BLINK tag), но оно не служит никаким полезным или маркетинговым целям.
Если вы не составили план, то программисты в первую очередь будут делать лёгкие/прикольные свойства. Затем они исчерпают время, и у вас не будете никакого выбора, кроме как распрощаться со своими планами сделать некое полезное/важное свойство.
Если вы начнёте составлять план, ещё до того как приступите к работе, вы поймете, что нужно удалить кое-что, таким образом, вы удалите лёгкое/прикольное свойство, и будете делать как раз полезное/важное свойство. Заставляя себя выбрать свойства от которых придётся отказаться, вы как бы включаете быструю перемотку вперёд, в создании более мощного, лучшего продукта с лучшим составом хороших свойств, который быстрее будет выпущен.
Помню я работал над Excel 5. Наш исходный список свойств был огромен и уходил далеко за пределы плана. Ё моё! - вот что мы себе говорили. Все эти свойства - супер важные! Ну как нам жить без мастера редактирования макросов?
Получилось так, что у нас не было выбора, и мы поудаляли, как нам казалось, самый костяк плана. Каждый чувствовал себя несчастным из-за этого. Чтобы успокоить наши чувства, мы просто сказали себе, что мы не удалили свойства, а просто отложили их до Excel 6, так как они были менее важные.
Приложение: То что вы должны знать об Excel
Одна из причин, по которой Excel –такое крутое средство работы с софтверными планами –та же самая по которой большинство Excel-программистов используют его для своих софтверных планов! (Не многие из них используют бизнес-сценарии "что если"... здесь они –программисты!)
Общий доступ Используйте команду Сервис/Доступ к книге чтобы каждый мог в одно время с другими открывать и редактировать план. Так как вся ваша группа постоянно будет модифицировать план, то это действительно помогает.
Автофильтр –крутой способ фильтровать план так, чтобы, например, видеть только назначенные вам свойства. В комбинации с сортировкой, он даёт возможность видеть только назначенные вам свойства в порядке важности, это уже реально ваш список "что сделать". Отлично!!!
Сводные таблицы –крутой способ смотреть итоги. Например, можно сделать диаграмму, показывающую оставшиеся часы по каждому разработчику по каждому приоритету. Сводные таблицы подобны пирожному со взбитыми сливками. Вы обязаны узнать, как ими пользоваться потому что они делают Excel в миллион раз мощнее.
Функция WORKDAY из пакета анализа Excel –крутой способ получать календарные даты из Безболезненного плана.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
По главной улице без оркестра
Автор: Джоэл Сполски
Переводчик: Маргарита Исаева
Редактор: Дмитрий Жемеров
2 декабря 2000
До недавнего времени лицензия нашей компании на программу запрещала её "разборку" (reverse engineering), т.е. попытки взглянуть на исходный код или модифицировать его каким-либо образом. Разные честные пользователи спрашивали, сколько мы хотим за лицензию на исходный код, чтобы они могли подправить пару вещей под свои задачи.
Хм... А почему вообще лицензия запрещает трогать исходники? Я не мог привести ни одного аргумента "против". Наоборот, я нашел достаточно аргументов "за" и немедлено изменил лицензионное соглашение. Так что теперь сидите и слушайте "историю старого ворчуна" из моего прошлого опыта.
Некоторое время тому назад, в 1995 году, я работал в Viacom'е, где наша небольшая группа отважных первопроходцев строила веб сайты для разнообразных Viacom'овских надобностей.
В те дни серверов приложений еще не было. Ребята из Sybase, когда вы говорили, что хотите использовать их БД в Интернете, настолько не въезжали в тему, что предлагали вам приобрести 150-долларовую лицензию для каждого пользователя, который подключается к вашему сайту. Netscap'овскому веб-серверу оставалось совсем чуть-чуть до версии 1.0.
И тут бравая компания Illustra стала всем объяснять, что ее СУБД прекрасно подходит для Веба. Illustra, знаете ли, позволяла легко добавлять новые типы данных путем написания кода на Си и подключения его к их СУБД. (Любой программист, который работал с СУБД, скажет вам, что это уже звучит достаточно подозрительно и опасно. Программа на Си? Которая вызывается из СУБД? Ой). Изначально все это задумывалось для таких интересных типов данных, как широта/долгота, временные ряды и т.п. А потом случился Веб. Illustra написала нечто под названием "Web Blade" и прилинковала его куда надо. "Web Blade" была недоделанной системой, которая якобы позволяла извлекать данные из БД и создавать динамические страницы "на лету", что в 1995 году было для всех главной проблемой.
Один мой коллега отвечал за построение сайта, посредством которого Blockbuster мог бы продавать — я не шучу — CD через Интернет. (Ведь именно это проходит в голову, когда думаешь про Blockbuster, правильно?) Короче, он решил, что Иллюстрa превосходно подойдет для этой задачи. Однако Иллюстра стоила что-то около 125 тыс. долларов, и вытрясти такую кучу денег из Viacom'а — это все равно что уговорить верблюда пройти через игольное ушко, т на это ушло определенное время. Мой коллега завел у себя в кабинете бумажный стаканчик с надписью "В фонд Иллюстры" и таким образом собирал по нескольку долларов в день. Босс вел тяжелые, продолжительные переговоры с Иллюстрой, и в конце концов соглашение было достигнуто. Мы инсталлировали Иллюстру и принялись за работу.
К сожалению, катастрофа не заставила себя долго ждать. Иллюстровский "Web Blade" был, мягко говоря, сырым и совершенно не отвечал предъявляемым требованиям. Он падал каждые несколько минут. Когда он все-таки работал, он предоставлял единственный язык программирования, который я когда-либо видел, который не был Тьюринг-эквивалентным, если вы можете себе такое представить. "Менеджер по лицензиям" постоянно отключал вас и ваш сайт молча умирал. Построение сайта с Web Blade было сущим кошмаром для моего коллеги, это было его Ватерлоо. Так что когда ко мне пришли и сказали: "Джоэль, ты делаешь сайт для MTV", я ответил "ой".
"Только пожалуйста, можно без Иллюстры"? — взмолился я.
"Ээээ... ну хорошо, но что же ты собираешься использовать взамен?" Никаких других серверов приложений в те дни не было. Не было ни PHP, ни AOLServer с TCL, Perl запускал по процессу на каждый запрос, и пенициллина у нас тоже не было, и вообще жизнь была ужасна.
И моя репутация была поставлена на карту. И я решил, что самым страшным в Иллюстре было вот что: когда она падала, с этим ничего нельзя было поделать. Если исходники доступны, думал я, когда Иллюстра падает, она падает тебе на колени вместе с отладчиком, и ты можешь попытаться найти и устранить причину. Возможно, придется не спать ночами в течение недели, отлаживая чей-то код, но по крайней мере у тебя есть шанс. Тогда как без исходного кода ты, как проигравший сражение, бредёшь по главной улице и без оркестра.
Вот тогда я и получил один из главных уроков в области программной архитектуры: для наиболее ответственных, критических задач вы должны использовать инструмент одним уровнем абстракции ниже, чем это было бы в идеале. Например, если вы пишете крутую трехмерную стрелялку (такую, как Quake, который вышел примерно тогда же) и вы планируете оставить конкурентов далеко позади с помощью крутейшей трехмерной графики, не используйте первую попавшуюся графическую библиотеку. Пишите свою собственную, потому что это фундамент вашей работы . Те, кто использует 3D библиотеки, такие как DirectX, делают это, потому что они пытаются выиграть на чем-то другом, отличном от качественной графики (может быть, на сюжете игры).
Именно тогда я решил больше не доверять никакому промежуточному серверу приложений, а написать мой собственный, на С++, используя библиотеку низкого уровня Netscape сервера. Потому что, по крайней мере, я знал, что если что-то пойдет не так, то проблема в моем коде, и я в состоянии ее устранить.
И это одно из самых важных преимуществ программ с открытым кодом (open source/free software), даже если вы можете себе позволить отвалить 125 тыс. долларов за Иллюстровский оркестр: по крайней мере, если что-то пойдет не так, вы сумеете это дело исправить хоть как-то, и вас не уволят, и все эти замечательные-хотя-и-слишком-активные ребята из MTV не будут на вас коситься.
Когда я сажусь проектировать систему, я должен решить, какие инструменты использовать. И хороший проектировщик использует или те инструменты, которым можно доверять, или те, которые можно починить. "Которым можно доверять" не означает, что они произведены какой-нибудь большой фирмой вроде IBM, которой положено доверять — это значит, что вы знаете точно, что они будут работать так, как надо. Я, например, знаю, что сегодня большинство Windows программистов доверяет Visual C++. Они могут не доверять MFC, но MFC поставляются с исходным кодом, так что если даже им нельзя доверять, их можно исправить, когда вы обнаружите, на какие зверства способна библиотека асинхронных сокетов. Так что поставить карьеру на карту MFC тоже можно.
Можно довериться Oracle DBMS по одной простой причине: она работает, и это всем известно. Вполне можно рассчитывать и на Berkeley DB, потому что, если Berkeley DB напортачит, вы идете и правите исходники. Но не стоит рисковать карьерой, используя не слишком известный инструмент с закрытым кодом. Такие программы вы можете использовать для экспериментов, но не как краеугольный камень своей карьеры .
Так что я начал думать, как сделать FogBUGZ беспроигрышной картой для трезвомыслящих инженеров. По счастливой случайности программа поставляется с исходным кодом — так уж устроены ASP. И это меня нисколько не беспокоит. В программе по отслеживанию глюков нет никаких магических секретных алгоритмов и высоких технологий. (По правде говоря, в любой программе очень мало магических секретных алгоритмов. Тот факт, что дизассемблировать программу и разобраться, как она работает, очень просто, означает гораздо меньше, чем полагают специалисты по авторскому праву). Меня не беспокоит, что люди читают мой код или модифицируют его для их собственных целей.
Другой риск модификации исходного кода, который вы купили у производителя, связан с тем, что когда производитель обновляет свою версию, вы можете потратить кучу времени, перенося свои изменения в эту новую версию. Здесь я тоже могу кое-чем помочь: если вы нашли ошибку и послали мне исправление, я включу ваше исправление в следующую версию. Это делается с целью убедить людей, в том, что a) FogBUGZ работает; b) если он не работает в каком-то очень важном для них аспекте, они могут внести исправления и не быть уволенными, и c) если уж так случится, что им придется исправлять ошибки, и исправления эти разумны, они попадут в код следующей версии и жизнь будет уже не такой собачьей.
И тут я уже слышу голоса поборников движения "открытый код": " Балда! Да просто сделай свою программу открытой — и все дела! У открытого кода этих проблем вообще нет!". И это замечательно. Только вот, чтобы моя крохотная компания с тремя программистами работала, нужны 40 000 долларов в месяц. Так что мы берем деньги за наши программы, и мы не извиняемся, потому что они того стоят. Мы не бежим, задрав штаны, за "открытыми сорцами", но мы заимствуем у них два-три принципа, чтобы выбор FogBUGZ был безопасным решением.
--------------------
1) Здесь автор иронизирует. "Blockbuster" — сеть салонов по прокату видеофильмов в США, и те, кто хотел бы проиобрести CD через Интернет, в те годы не стали бы искать их на сайте компании Blockbuster.
2) В оригинале "herding cats", т.е. пасти кошек — идиоматическое выражение, означающее трудную задачу.
3) Практически все языки программирования (такие как Fortran, Pascal, C, Java и т.д.) являются "эквивалентными по Тьюрингу" (Turing-complete). Язык, который не является "эквивалентным по Тьюрингу", не обладает достаточной мощностью (например, в нем может отсутствовать оператор цикла, как в раннем SQL), так что определенные классы задач не могут быть на нем запрограммированы.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Пожалуйста, сэр, могу ли я получить компоновщик?
Автор: Джоэл Сполски
Переводчик: Анар Мустафаев
28 января 2004
По неизвестной причине, превосходная и супер современная среда разработки .NET компании Microsoft пропустила один их ключевых инструментов… инструмент который был обычным делом в средах разработки программного обеспечения с, ну, примерно 1950 года, и настолько очевидным, что кажется невероятно странным, что никто не обратил внимание на тот факт, что в .NET, на самом деле, его нет.
О каком инструменте идет речь? О компоновщике (linker). Вот что он делает: собирает откомпилированную версию вашей программы с откомпилированными версиями библиотечных функций, которые ваша программа использует. Затем, он удаляет те библиотечные функции, которые ваша программа не использует. И в конце концов, компоновщик создает один бинарный выполняемый файл, который люди могут запустить на своих компьютерах.
Вместо этого, в .NET реализована идея «среды времени выполнения» (runtime)… большая, 22 мегабайтная, парообразная куча кода, которая динамически компонуется и которую каждый обязан записать на свой компьютер перед тем как использовать .NET приложения.
Среды выполнения - это проблема очень похожая на проблему с DLL, потому что если приложение 1 было разработано для среды выполнения 1, и выходит среда выполнения версии 2, то, внезапно, по какой-то непредсказуемой причине приложение 1 перестает правильно работать. Например, сейчас, после обновления среды выполнения с версии 1.0 до 1.1, наша внутренняя корпоративная контрольная панель округляет количество продаж до четвертого десятичного знака. А обычно несовместимости бывают еще хуже.
Фактически .NET включает в себя обширную технологическую систему называемую «явности» (manifests), которые явно сложны и задуманы для того чтобы каким-то образом только правильная среда выполнения могла быть использована с данным приложением, но я не знаю никого, кто может разгадать как их использовать.
Все это требует рассказать одну историю. На вечеринке в Fog Creek, в канун Нового Года, мы хотели чтобы в главной комнате несколько компьютеров показывали обратный отсчет времени до полуночи. Майкл написал приложение на C# с WinForms за 60 секунд. Это отличная среда разработки.
Моя работа заключалось в том что бы записать программу countdown.exe на три компьютера и запустить ее. Это звучит просто.
Как бы ни так. Двойной щелчок на EXE и я получаю смешное недружелюбное сообщение об ошибке где-то в mscoree.dll или что-то такое, с неуместным дампом моего пути. Естественно, нет сомнения в том что среда выполнения .NET просто не была проинсталированна. К счастью я программист и сразу определил в чем проблема.
Как я инсталлирую среду выполнения? “Простейший” путь через Windows Update. Но Windows Update сначала заставляет меня проинсталлировать все критические обновления, а только потом среду выполнения. Это, разумно, да? Два из “критических” обновлений – это Windows service pack и новая версия Internet Explorer, и оба требуют перезагрузить компьютер.
Как я уже говорил, для запуска этого маленького .NET приложения мне нужно загрузить 70 или 80 мегабайт (хорошо, что у нас скоростной доступ в Интернет) и перезагрузиться три или четыре раза. И это в софтверной компании! Я знаю как долго это длится, потому что когда загрузка началась в первый раз, я включил «» на большом экране, и к тому времени когда фильм закончился, инсталляция почти завершилась. Каждые десять минут во время просмотра фильма я должен был вскакивать, бежать к компьютеру, чтобы нажать ОК в каком-нибудь дурацком диалоговом окне.
Этого достаточно чтобы вызвать разочарование от использования доморощенных программ. Но подумайте о нашем продукте . Практически все наши пользователи загружают перед тем как купить этот продукт. Им надо загрузить около 9 Мб и не предъявляется никаких дополнительных требований. И, практически, пока никто их этих пользователей не имеет среды выполнения .NET.
А если мы попросим пользователей из небольших организаций и домашних пользователей, сначала пройти через весь ад инсталляции среды выполнения длительностью с целый фильм, то, я думаю, мы потерям 95% из них. Они пока не клиенты, они потенциальные клиенты, и я не могу позволить себе отказаться от 95% моих потенциальных клиентов только ради использования более удобной среды разработки.
“Но, Джоэл”, могут мне сказать, “это же ясно, что скоро у достаточного количества пользователей будет эта среда выполнения и тогда проблема исчезнет.”
Я тоже так думал, а потом обнаружил что Microsoft поставляет новую версию среды выполнения каждые шесть или двенадцать месяцев. Понемногу увеличивающееся количество людей имеющих ее опять падает до нуля. И будь я проклят, если я буду тестировать мое приложение на трех различных версиях среды выполнения только для того чтобы получить прирост клиентов на 1,2% на одну из трех версий.
Я просто хочу все скомпоновать в один статический EXE файл, который для запуска не предъявляет никаких особых требований. Мне не важно, что он несколько больше. Все что мне было бы необходимо - это функции которые я действительно использую, интерпретатор байт кода и немного от среды выполнения. Мне не нужен целый компилятор C# который является частью среды выполнения. Я уверяю что код CityDesk не нуждается в компиляции какого-то ни было программного кода на C#. Мне не нужны целых 22 МБайт. Самое большее что мне нужно это 5 или 6 МБайт.
Я знаю компании, которые обладают технологией сделать это, но им нужно разрешение от Microsoft чтобы распространять части среды выполнения, такие как интерпретатор байт-кода. Эй, Microsoft, проснись, дай нам замечательный кусочек технологий 1950-х годов, и позволь мне сделать один EXE файл, который запускается на любом компьютере с ОС Win 98 или более поздней без всяких дополнительных требований. Но нет, .NET фатально не дружелюбна к пользователю, который скачивает софт.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Работа над ошибками малой кровью
Автор: Джоэл Сполски
Переводчик: Александр Башков
Редактор: Юрий Удовиченко
8 ноября 2000 года
Первые версии интерпретатора языка BASIC на компьютере TRS-80 позволяли заводить только две строковые переменные, A$ и B$. По его образу и подобию я был произведён на свет только с двумя ячейками для хранения информации об ошибках в голове. Одновременно я могу помнить информацию только о двух ошибках в программе. Если вы попросите меня запомнить третью, то какая-нибудь из трёх обязательно упадёт на пол, закатится под диван и затеряется там в реликтовых залежах пыли.
Ведение базы данных ошибок в программе - один из признаков хорошей программистской команды. Не перестаю удивляться тому, как редко разработчики прибегают к этому. Одно из типичных программистских заблуждений — это вера в то, что можно сведения о всех ошибках удержать в памяти или на отрывных листочках.
Если вы позволите мне отнять немного вашего времени, я расскажу вам о приятном, совершенно безболезненном способе отслеживать ошибки в программах в духе предыдущих статей: "графики работ малой кровью" и "спецификации малой кровью".
Прежде всего вам понадобится база данных (СУБД). Команда из двух человек, пописывающих чуть-чуть кода по выходным, вероятно, удовлетворится простым текстовым файлом. Более крупной команде уже потребуется настоящая система отслеживания ошибок. В настоящий момент продается несчётное количество подобных продуктов. (Беззастенчивая самореклама: одну из них — — написали мы в Fog Creek Software. Это веб-ориентированная, несложная в использовании и достаточно мощная программа).
Давайте последим за какой-нибудь ошибкой от момента рождения до конца её бренного пути. Возьмём для примера ошибку 1203. Вот какую информацию о ней выдаёт база данных:
* Запустить Bee Flogger
* Создать новый документ без имени содержащий букву "а"
* Щёлкнуть кнопку ftp на панели
* Попробовать загрузить документ по ftp на сервер
ОШИБКА: ftp сервер не отвечает.
Команда ps -augx показывает, что ftp сервер вообще не выполняется.
В корневом каталоге содержится дамп памяти.
ТРЕБУЕТСЯ: ftp сервер не должен падать.
1 ноября 2000 Джилл, очень-очень хороший тестер, поручила работу над ошибкой Вилли, ведущему разработчику.
2 ноября 2000 (вчера) Решено - Исправлять не будем - Вилли, ведущий разработчик.
Не наш код, Джилл. Это proftpd, входящий в поставку Linux.
2 ноября 2000 (вчера) Возобновлено (поручено Вилли, ведущему разработчику) Джилл, очень-очень хоршим тестером.
Неубедительно. Мне никогда не удавалось уронить proftpd другими ftp клиентами. Наш же клиент роняет его каждый раз. Ftp серверы сами по себе не падают.
3 ноября 2000 (сегодня) Вилли, ведущий разработчик поручил работу над ошибкой Майку, простому программисту.
Майк, взгляни-ка сюда. Может твой код в клиенте делает что-то не то?
3 ноября 2000 (сегодня) Решено - Исправлено. Майк, простой программист.
Я думаю, что я передавал имя пользователя вместо пароля или что-то типа того...
3 ноября 2000 (сегодня) Реактивировано (поручено Майку, простому программисту) - Джилл, очень-очень хорошим тестером.
Всё то же самое в 2001-й сборке.
3 ноября 2000 (сегодня) Отредактировано Майком, простым программистом.
О как! Очень странно. Надо будет взглянуть внимательнее.
3 ноября 2000 (сегодня) Отредактировано Майком, простым программистом.
Мне кажется это в MikeyStrCpy()...
3 ноября 2000 (сегодня) Решено - Исправлено Майком, простым программистом.
Уфффф!!! Исправлено!
3 ноября 2000 (сегодня) Закрыто Джилл, очень-очень хорошим тестером.
Похоже-таки исправлено в сборке 2022 - закрываю.
Итак, вот что произошло.
Майк, простой программист, колдовал над новой возможностью своей превосходной программы для макинтошей: ftp клиентом. В один прекрасный момент из хулиганских побуждений он написал свою собственную функцию копирования строк. Вот им за их дурацкое требование повторного использования кода! Ха-ха-ха!
Беда приходит нежданно, Майк, когда ты не используешь повторно код! На этот раз никто не ждал, что Майк забудет завершить копируемую строку нулём. И ошибка осталась незамеченной, потому что при отладке строка копировалась в заранее обнулённую область памяти.
Позже на той же неделе, Джилл, очень-очень хороший тестер, терзала код, нажимая все клавиши подряд и выполняя другие, столь же коварные тесты. (По странному совпадению, практически всех хороших тестеров зовут Джилл или в крайнем случае Джиллиан). Внезапно произошло что-то очень странное — ftp сервер, на котором она проверяла клиента, упал! Да, я знаю, что это был Линукс, а компьютеры под Линуксом никогда не падают (только вот не надо фыркать, вы не на slashdot'е), но эта чёртова штука таки упала! А ведь Джилл даже не дышала на ftp сервер. Она просто пыталась загрузить на него файл, используя код для Mac-а, написанный Майком.
Поскольку Джилл была очень-очень хорошим тестером, она аккуратно вела запись всех своих действий. Она перезагрузила всё, что было можно. Начала повторять свои действия на чистой машине, и — гляньте-ка — это случилось снова! Ftp сервер опять упал! Дважды за один день! Вот тебе, Линус!
Джилл взглянула на запись своих действий. Там было порядка двадцати шагов. Некоторые из них, похоже, не имели отношения к проблеме. После некоторых экспериментов Джилл сократила число действий до четырёх, которые всегда вызывали ошибку. Теперь она была готова описать ошибку.
Джилл ввела информацию об ошибке в базу данных. Кстати, даже сам процесс записи информации об ошибке требует определенной дисциплины: бывают хорошие описания, а бывают и плохие.
Три составные части хорошего описания ошибки
И говорил Господь, и сказал Он: "Сначала следует тебе вынуть чеку святую. Затем следует сосчитать до трёх, не более и не менее. Три — число, до коего должен ты считать; и количество счёта твоего должно быть три. До четырёх не следует считать, а равно и до двух, кроме как ежели после двух последует три. Пять категорически исключается. И когда число три, будучи по счёту третьим числом, достигнуто будет, не сумняшеся метни Святую Гранату Антиохову во врага своего, который, будучи грешен передо Мною, ласты-то и склеит."
Монти Питон и Святой Грааль
Запомнить правила составления хорошего описания ошибки совсем нетрудно. Каждое хорошее описание ошибки должно содержать ровно три вещи:
Какие шаги привели к ошибке. Что вы ожидали увидеть. Что вы в самом деле увидели.
Просто, да? Увы, нет. В бытность свою программистом я периодически получал описания ошибок, где отсутствовала та или иная часть.
Если вы не расскажете мне, как воспроизвести ошибку, я, наверное, просто не пойму, о чём вы вообще говорите. "Программа виснет и оставляет на столе дурно пахнущий объект, похожий на мешок навоза". Отлично, дорогой. Но я ничем не смогу тебе помочь, пока ты не расскажешь мне, что именно ты делал. Хочу отметить, что существуют две ситуации, в которых трудно точно воспроизвести действия, ведущие к ошибке. Бывает, что просто никак не вспомнить, какие именно шаги привели к ошибке, или, бывает, информацию об ошибке вам прислали из полевых условий. (Какие ж они полевые? Ни пшеницы, ни васильков. Ну да ладно.) Вторая ситуация — это когда ошибка воспроизводится не каждый раз. Но и тут стоит составить перечень действий, отметив, что ошибка происходит не всегда. В этих случаях бывает очень сложно локализовать ошибку, но попробовать можно.
Если вы не опишете, чего ожидали, я могу не понять, почему это, собственно, ошибка. На заставке следы крови. И что с того? Может быть я порезал палец, когда кодировал это место. А вы чего ожидали? А-а-а! Вы говорите, в спецификации написано "без крови"? Ну тогда понятно, почему вы решили, что это ошибка.
Часть три. Что вы в самом деле увидели. Если вы мне не расскажете об этом, я и не узнаю, в чём же ошибка. Ну, это и так понятно.
Вернемся к нашим баранам
Короче, Джилл ввела информацию об ошибке. В хорошей системе учёта ошибок работа над ошибкой автоматически поручается ведущему разработчику проекта. И в этом кроется вторая идея — ошибкой, пока она не закрыта, в каждый заданный момент времени должен заниматься только один человек. Ошибка подобна горячей картофелине — если она у вас, или сами ею занимайтесь, или перекиньте кому-нибудь ещё.
Вилли, ведущий разработчик, взглянул на описание ошибки и решил, что, вероятно, что-то не в порядке с ftp сервером, и пометил её как "исправить невозможно". В конце концов, не они же писали код ftp сервера.
Когда ошибка разрешена, она назначается обратно тому, кто открыл её. Это важный момент. Ошибка не исчезает только потому, что программист так решил. Золотое правило гласит, что закрыть ошибку может только тот, кто её открыл. Программист может только "решить" ошибку, в смысле — "ага, я думаю, ошибка исправлена", но реально закрыть ошибку и убрать её из списка может только человек, увидевший её впервые. Только он может подтвердить, что ошибка в самом деле исправлена, или согласиться с тем, что по каким-либо причинам исправить её невозможно.
Джилл получила е-мэйл: ошибка опять вернулась к ней. Она посмотрела комментарии Вилли. Что-то ей показалось неверным. Куча народа годами использует этот ftp сервер с различными приложениями, и он не падает. Это происходит только когда используется код Майка. Джилл реактивировала ошибку, объяснив своё решение, и вернула её на рассмотрение Вилли. Вилли поручил ошибку Майку для исправления.
Майк изучил ошибку, думал долго и упорно, но, тем не менее, сделал неверные выводы. Он исправил несколько несвязанных между собой ошибок и решил, что в их число попала ошибка Джилл.
Ошибка вернулась к Джилл с описанием "решена-исправлена". Джилл попробовала повторить шаги, ведущие к ошибке, и глядите-ка, ftp сервер опять упал. Она опять реактивировала ошибку и теперь поручила её исправление непосредственно Майку.
Майк был озадачен, но, в конце концов, он-таки нашёл источник ошибки. (Догадались, что это было? Я оставлю ответ на этот вопрос в качестве домашнего задания читателю. В тексте содержится достаточно подсказок). Он исправил её, проверил, и — эврика! Ftp сервер больше не падал. Опять он пометил ошибку как "решено-исправлено". Джилл тоже повторила все действия, приводившие к ошибке, и убедилась, что ошибка исправлена. После этого она с чистой совестью закрыла её.
Десять рекомендаций для успешного отслеживания ошибок
Хороший тестер должен всегда стремиться сократить до минимума число действий, необходимых для воспроизведения ошибки. Следование этому правилу может оказать неоценимую помощь программисту, который будет искать эту ошибку. Помните, что закрыть ошибку может только тот, кто её открыл. Кто угодно может решить её; но только тот, кто первым увидел ошибку, может быть уверен, что то, что он видел - исправлено. Существует много способов разрешить ошибку. Программа FogBUGZ, например, позволяет сделать это следующими способами: исправлена, не подлежит исправлению, отложено, не воспроизводится, повторная, особенность дизайна. Не воспроизводится — значит, что никто не смог воспроизвести ошибку. Программисты часто используют этот вердикт, если в описании ошибки опущены шаги для воспроизведения ошибки. Вы должны аккуратно отслеживать версии программы. Каждая сборка программы, которая передается тестеру, должна иметь номер версии, чтобы несчастный тестер не проверял ошибку, которая и не должна быть исправлена в этой версии. Если вы программист, и вам не удается сподвигнуть тестеров на использование базы данных учёта ошибок, перестаньте обращать внимание на информацию об ошибках, переданных вам в любой другой форме. Если ваш тестер присылает вам информацию об ошибке по электронной почте, отправляйте его письма обратно с короткой припиской: "пожалуйста, поместите эту информацию в базу данных. Я не имею возможности отслеживать информацию об ошибках, поданных с помощью электронной почты". Если вы тестер, и у вас проблеммы с программистами, которые не используют базу данных учёта ошибок, не давайте им информацию об ошибках ни в какой другой форме. Помещайте информацию в базу данных, она сама сообщит им об этом через электронную почту. Если вы программист, и некоторые из ваших коллег не используют базу данных учёта ошибок, начните назначать им ошибки через базу. В конце концов, до них дойдёт. Если вы менеджер, и вам кажется, что никто не использует базу данных учёта ошибок, которую вы выбили большой кровью, начните назначать программистам новые задачи в форме ошибок. Система отслеживания ошибок также является отличным средством учёта заданий. Избегайте соблазна добавить новые поля в базу данных. Примерно раз в месяц кому-нибудь в голову приходит "светлая" идея добавить к базе данных новое поле. Вам приносят самые разные мудрые идеи, например: указывать файл, в котором обнаружена ошибка; или вести учёт, в каком проценте повторов ошибка воспроизводится; вести учёт версий всех DLL, которые были запущены на компьютере, когда произошла ошибка; и так далее. Очень важно не поддаваться этим идеям. Иначе рано или поздно экран ввода информации об ошибке будет представлять собой форму с тысячью полей, которые необходимо заполнить, и никто не будет вводить эту информацию. Чтобы база данных учёта ошибок приносила толк, ее должны использовать все. И если ввод информации об ошибке будет требовать слишком больших усилий, люди найдут обходные пути.
Если вы пишете код, пусть даже в одиночку, и не ведёте систематизированный учёт всех найденных в коде ошибок, вы обречены поставлять низкокачественный продукт. В хороших командах база данных учёта ошибок не просто используется, это становится привычкой. И программисты начинают её использовать для поддержки своих рабочих планов, список назначенных им ошибок делают стартовой страницей своего браузера. И в конце-концов, многие начинают мечтать о тех временах, когда можно будет поручить завхозу ликвидацию ошибки по отсутствию пива в ближайшем холодильнике.
В английском оригинале статья называется
Джоель Спольски - основатель , небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Совет студентам изучающим вычислительную технику
Автор: Джоэл Сполски
Переводчик: Анар Мустафаев
2 января 2005
Несмотря на тот факт, что еще год или два назад я рыдал о том, что классические Windows программы сделали ручкой будущему, однако время от времени студенты шлют мне email с просьбой дать совет о том, как строить карьеру. A ведь сейчас сезон приема на работу, поэтому я подробно изложу свои стандартные рекомендации, которые они смогут прочесть, посмеяться и выбросить.
К счастью, большинство студентов достаточно смелы, чтобы никогда не стесняться спрашивать советов у старших, что в области вычислительной техники (Computer Science) весьма уместно, потому что старшие склонны говорить устаревшие глупости, подобные этим: “спрос на операторов превысит 100 000 000 к 2010 году” или “lisp программисты сейчас очень востребованы”.
Поэтому вам лучше не обращать внимание на то, о чем я здесь говорю, а вместо этого заняться созданием , которая помогает студентам находить людей, с которыми можно идти в ногу со временем.
И все таки.
Если программирование компьютеров вам в удовольствие - молитесь: вы в числе той немногочисленной группы людей, которая может зарабатывать неплохие деньги делая то, что нравится. Большинство людей лишены такого счастья. Идея, что вы можете “любить свою работу” – это современная концепция. Раньше предполагалось, что работа – это некая неприятная вещь, которую вам приходиться делать, для того чтобы заработать денег на то, чем вы будете заниматься, когда вам стукнет 65 и вы сможете уйти в отставку, и только если вы сможете себе позволить это занятие, и если вы не очень стары, и дряхлы для этих дел, и если эти дела не требуют крепких коленей, хороших глаз, и не требуют способности проходить 20 футов без отдышки, и т.д.
Так, о чем я говорил? Ах да, совет.
Без дальнейших отступлений, вот Семь Частей Бесплатного совета Джоэла для студентов изучающих вычислительную технику (будет все же лучше если вы за них заплатите):
Научитесь писать до окончания учебы.
Выучите С до окончания учебы.
Выучите микроэкономику до окончания учебы.
Не пропускайте лекции не относящиеся к вычислительной технике, только потому что они скучны.
Возьмите интенсивные курсы программирования.
Перестаньте беспокоиться о том, что вся работа переносится в Индию.
Не важно чем вы занимаетесь, найдите хорошую летнюю практику.
Теперь, перед объяснениями, если только вы не настолько доверчивы, чтобы выполнять все это только потому что я вам это сказал, на всякий случай добавлю еще: 8. Найдите профессиональную помощь, чтобы не потерять самоуважение.
Научитесь писать до окончания учебы.
Был бы Linux так успешен если бы Линус Торвальд не проповедовал бы его? Это был дар, такого выдающегося хакера как Линус, донести свои идеи написанные на английском через электронную почту и списки рассылки, что и сделало Linux таким привлекательным для всемирной бригады волонтеров.
Вы слышали о самой последней моде – экстремальном программировании? Ну, не вдаваясь в то, что я думаю об XP, причина, по которой вы слышали об этом, состоит в том, что эта концепция была разрекламированна очень одаренными писателями и ораторами.
Даже в маленьком масштабе, если посмотреть на любую организацию, программисты с наибольшой силой и влиянием – это те, кто пишет и говорит на английском чисто, убедительно и комфортно. Это позволяет им быть еще и хвастливыми, но с этим ничего не поделаешь.
Я не найму программиста, который не может писать и писать хорошо на английском. Если вы можете писать, где бы вы не работали, то вскоре обнаружите, что вас просят написать спецификации, а это означает, что у вас уже есть рычаги оказывать влияние и вас заметило руководство.
В большинстве колледжей есть некие предметы “интенсивного письма”. Это означает, что вам придется написать огромное количество материала, чтобы сдать экзамены по этим предметам. Обратите внимание на эти предметы и возьмите их! Ищите предметы в любой области в которых есть задания на каждую неделю или на каждый день.
Заведите дневник или веб-блог. Чем больше вы пишите тем легче вам будет это делать, и наоборот, чем легче это делать тем больше вы будете писать.
Выучите С до окончания учебы.
Часть вторая: С. Обратите внимание я не сказал С++. И хотя С используется все реже и реже, он остается лингва-франка для работающих программистов. Это тот язык, который используется чтобы общаться друг с другом и, что еще более важно, он гораздо ближе к машине, чем “современные” языки, которым вас учат в колледже: ML, Java, Python, какому бы новомодному мусору не учили сегодня. Вам нужно, как минимум, семестр чтобы стать ближе к машине, . Вы никогда не сможете работать над компиляторами и операционными системами, а это одни из самых лучших рабочих мест. Вам никогда не доверят создавать архитектуру больших проектов. Меня не интересует сколько вы знаете о последовательностях, замыканиях и обработке исключений, если вы не можете объяснить почему while (*s++ = *t++); копирует строку, или это для вас не одна из самых естественных вещей в мире, ну, тогда вы программируете основываясь на суевериях, подобно доктору, который не зная анатомии отпускает рецепт основываясь на том, что говорит аптекарша.
Выучите микроэкономику до окончания учебы.
Почему студенты изучающие вычислительную технику должны изучать экономику? Потому что тот программист, который понимает основы бизнеса, будет более ценным программистом для бизнеса, чем тот программист, который их не понимает. Все это делается именно для бизнеса. Я даже не могу назвать сколько раз я был в замешательстве, от выдвигаемых программистами сумашедших идей, которые имели смысл в кодировании, но не имели никакого смысла в капитализме. Если вы понимаете всю эту кухню, то вы более ценный программист, и вы будете за это вознаграждены, по тем же причинам по которым вы возьметесь изучать микроэкономику.
Не пропускайте лекции не относящиеся к вычислительной технике, только потому что они скучны.
Пропускать лекции не относящиеся к вычислительной технике – это отличный способ получить низкую среднюю оценку (GPA2).
Никогда недооценивайте насколько важна ваша средняя оценка. Множество агентов по найму и менеджеров по персоналу, включая меня, сразу же ищут среднюю оценку когда просматривают резюме, и мы не собираемся извиняться за это. Почему? Потому что средняя оценка, более чем любое другое число, отражает сумму того, что дюжины профессоров за долгий период и в различных ситуациях думают о вашей работе. Вступительный экзамен (SAT3)? Ха! Да это один тест на несколько часов. Средняя оценка отражает сотни письменных заданий и промежуточные экзамены и посещяемость за четыре года. Да, у этой оценки есть свои недостатки. За годы был подъем оценки. Средняя оценка ничего не говорит о том набрали ли вы ее посещая легкие лекции по домашней экономике в Podunk Community College или получили уровень образование изучая квантовую механику в Caltech. В конце концов, после того как я отсею тех кто имеет среднюю оценку в 2.5 балла из Podunk Community, я спрашиваю о копиях атестатов и рекомендации. И затем я смотрю на твердые высокие оценки, и не только по вычислительным наукам.
Почему же меня, работодателя для разработчиков программного обеспечения, заботит ваша высокая оценка по истории Европы? Как никак, история скучна. Ах, так вы говорите, что я должен нанять вас, потому что вы не собираетесь упорно работать если работа скучна? Ну, в программировании тоже много скучных вещей. Любая работа имеет свои скучные моменты. И я не хочу нанимать на работу людей, которые желают выполнять только приятную работу.
В колледже я взял курс культурной антропологии, потому что я думал, что я должен научиться кое-чему из антропологии и этот курс выглядел как интересный исследовательский курс.
Я получил высшую оценку. И если я смог это сделать, то и вы сможете.
Возьмите интенсивные курсы программирования.
Я точно помню момент когда я поклялся никогда не заканчивать институт.
Это был курс , преподаваемый динамичным Ленором Зуком (Lenore Zuck) в Йеле (Yale), одним из ярчайших представителей очень яркого факультета вычислительной техники.
Теперь, мои мрачные воспоминания не окажут должной чести этой области, но все же позвольте мне хоть как-то довести начатое до конца. Суть формальной логики состоит в том что вы можете доказать истинность одних вещей, потому что другие истинны. Например, спасибо формальной логике, “все кто получает хорошие оценки найдут работу” плюс “Джони получил хорошие оценки”, позволяет нам открыть новый истинный факт: “Джони найдет работу”. Это все очень изящно и займет всего десять секунд чтобы разобраться со всем тем, что есть полезного в формальной логике, поэтому вы остаетесь с чем-то забавным, но бесполезным.
Теперь, динамическая логика – это тоже самое плюс время. Например, “после того как включите свет, вы увидите свои туфли” плюс “свет был включен в прошлом” подразумевает “вы видите ваши туфли”.
Динамическая логика очень притягательна для таких великолепных теоретиков как профессор Зук, потому что она дает надежду, что вы сможете формально доказать вещи связанные с компьютерными программами, что может быть очень полезно. Например, вы могли бы формально доказать, что флеш карточка Mars Rover не будет переполняться и сама себя перезагружать на протяжении всего дня, в то время, как она движется вокруг красной планеты в поисках марсианина Марвина.
На первой же лекции доктор Зук полность заполнил две доски и стену рядом доказывая, что если у вас есть выключатель света и выключатель выключен и вы переключаете выключатель, то свет зажется.
Доказательство было безумно запутанным и весьма подверженно ошибкам. Было труднее доказать, что доказательство правильно чем убедить себя в том факте, что при включении выключателя света - включается свет. Конечно несколько досок доказательства содержало несколько пропущенных шагов, пропущенных потому что они были слишком неинтересны чтобы углубляться в них формально. Много шагов было достигнуто ветхо-заветным методом Доказательство по Индукции, другие доказательством от противного и для оставшихся использовались доказательства аспирантов.
Моим домашним заданием было доказать утверждение: если свет был выключен и сейчас он включен докажите, что вы переключили выключатель.
Я попытался. Я действительно попытался.
Я провел часы в библиотеке пытаясь.
После пары часов я нашел ошибку в доказательстве доктора Зука, которое я пытался имитировать. Возможно я неправильно списал, но это позволило мне обнаружить одну вещь: если на то чтобы доказать тривиальную вещь уходит три часа на заполнение досок, позволяя вкрасться сотням возможным ошибкам, то этот механизм никогда не сможет доказать то, что действительно интересно.
Этот вывод не касается динамических логиков: они занимаются этим не потому что это полезно, а потому что такова их должность.
Я бросил лекции и поклялся никогда не оканчивать институт по вычислительной технике.
Мораль истории такова: вычислительная техника – это не тоже самое, что разработка программного обеспечения. Если вам повезет, институт может иметь достойный курс разработки программ, хотя, скорее всего этого не будет, потому что элитные школы думают, что обучение практическим навыкам лучше оставить професионально-техническим училищам и тюремным реабилитационным программам. Вы можете изучить море программирования везде. Мы Йельский Университет, мы Формируем Будущих Лидеров Мира. Вы думаете, что ваша $160000 плата за обучение дает вам право изучать циклы while? Вы думаете, что мы здесь, безответственный Java-семинар в гостинице Marriott в аэропорту? Фи!
Беда в том что у нас нет профессиональных школ по разработке программного обеспечения, поэтому, если вы хотите быть программистом, то вашей профилирующей дисциплиной возможно является вычислительная техника. Она вполне подходит для этого, но это другой предмет, это не разработка программ.
Вам может повезти, и вы найдете множество интенсивных курсов по программированию на кафедре вычислительной техники, точно также, как есть множество предметов на кафедре истории, на которых вы будете писать достаточно, для того чтобы научиться писать. И это лучшие предметы чтобы заниматься. Если вы любите программирование, не смущайтесь если не понимаете сути этих курсов в лямбда-исчислении или линейной алгебры где вы даже не прикасаетесь к компьютеру. Ищите 400-уровневый курс с Practicum (лат. практика) в названии. Это попытка Либеральной Вычурной Пропуканой Администрации спрятать нужный (до дрожи) курс вырядив его латинским названием.
Перестаньте беспокоиться о том, что вся работа переносится в Индию.
Так, ну, во-первых, если вы уже в Индии, то вам никогда и не нужно было об этом беспокоиться, поэтому и не начинайте беспокоиться о том, что рабочие места переносятся в Индию. Это замечательные рабочие места, наслаждайтесь ими.
Но я продолжаю слышать о том, что число абитурьентов поступающих на факультеты вычислительной техники опасно снижается. Я слышал, что один человек сказал по этому поводу, что “студенты опасаются вступать в ту область в которой вся работа переносится в Индию”. Это так ошибочно по многим причинам. Первое – выбирать карьеру основываясь на сегодняшних причудах бизнеса глупо. Второе – программирование это невероятно хороший трейнинг для всех типов поразительно интересных рабочих мест, таких как инжиниринг бизнес процессов, даже если единичное рабочее место по программированию и переносится в Индию или Китай. Третье – поверьте мне, еще остается невероятно много места для действительно хороших программистов, и здесь, и в Индии. Конечно, полно безработных ИТ специалистов, которые сильно шумят о том, как долго они были без работы, но знаете что? Рискуя послать их, скажу, что у действительно хороших программистов есть работа. Четвертое – у вас есть идеи получше? Чем вы будете заниматься если ваш профилирующий предмет история? У вас просто нет выбора, кроме как пойти в юридическую школу. И здесь имеется одна вещь, на которую я хочу обратить ваше внимание: 99% юристов ненавидят свою работу, ненавидят каждую ее минуту, а они тоже работают по 90 часов в неделю. Как я уже говорил: если программирование компьютеров вам в удовольствие - молитесь: вы в числе той немногочисленной группы людей, которая может заработать неплохие деньги делая то, что нравится.
Все равно, я не думаю что студенты действительно думают об этом. Уменьшение числа учащихся на факультетах вычислительной техники – это возвращение исторически нормального уровня после большого пузыря вызванного дотком манией. Пузырь состоял из людей, которые в действительности не любили программирование, но думали, что поступив на факультет вычислительной техники найдут сексульно-привлекательную высоко оплачиваемую работу и шансы в 24 года выбросить акции на рынок и разбогатеть. Такие люди, к счастью, давно ушли.
Не важно чем вы занимаетесь, найдите хорошую летнюю практику.
Умные агенты по найму кадров знают, что люди, которые любят программирование написали базу данных для своего дантиста в 8 классе, обучались в компьютерном лагере три лета перед колледжем, построили систему управления контентом для газеты лагеря и летом проходили практику в сотверных компаниях. Вот это они ищут в вашем резюме.
Чтобы упростить вашу жизнь и чтобы подчеркнуть насколько это заказная статья, моя компания Fog Creek Software предлагает , которая будет отлично смотреться в вашем резюме. “Вы научитесь кодированию, разработке программ и бизнесу в Fog Creek Software более чем где либо еще”, говорит Бен, один из наших практикантов прошлого лета, и это не все, потому что я послал вышибалу в его общежитие, чтобы заставить Бена сказать это. Заявки принимаются до 1 февраяля. Торопитесь.
Если вы последуете моему совету, вы тоже можете закончить продавать акции по Microsoft’овски слишком быстро, отвергните предложение Google, потому что хотите иметь ваш собственный офис с дверью, или принять другие глупые жизненые решения, тут я не виноват. Я же говорил вам не слушайте меня.
1. NPV (Net Present Value) - Чистый дисконтированный доход (в некоторых источниках чистая приведенная стоимость) показывает, превышает ли текущая стоимость ожидаемых доходов/расходов по проекту (дисконтированный доход) инвестиционные затраты в начальный момент времени.
2. GPA (Grade Point Average) – средняя оценка по четырех бальной шкале.
3. SAT (Scholastic Assessment Test) – в США тест готовности к обучению в высших учебных заведениях, подобный единому государственному экзамену.
4. В оригинале mall folding shirts. В сети магазинов The Gap, Banana Republic и др., которые продают одежду, одежда складывается в большие кипы, которые аккуратно разложены на столах. Покупатели берут одежду из этих кип, чтобы рассмотреть и перемешивают ее. Поэтому эти магазины нанимают студентов для складывания и раскладывания одежды.
5. A&F (Abercrombie and Fitch) – один из таких магазинов одежды в которых студенты раскладывают одежду. Enterprise Rent a Car – компания по сдаче автомобилей в аренду, имеет репутацию места работы для веселых молодых работников. Они выполняют весьма лакейскую работу, но им надо что-то написать в своем резюме, поэтому они пишут “помогал людям в их арендных нуждах”, что звучит гораздо лучше чем “мыл машины сдаваемые в аренду, когда они приходили грязными”.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Стратегические заметки II: Вопрос о курице и яйце
Автор: Джоэл Сполски
Переводчик: Борис Надион
Редактор: Любовь Абрамова
24 мая 2000
Смысл рекламы - это лгать, не боясь быть пойманным. Большинство организаций, начиная рекламную кампанию, просто берут самую неприглядную правду про свою организацию, переворачивают все вверх тормашками ("лгут") и впихивают это потребителю. Давайте назовем это "интерпретацией". Например, полет на самолете неудобен из-за необходимости пребывания в замкнутом пространстве, а служащие авиакомпаний грубы и неприятны, да и на самом деле вся система коммерческих перелетов специально задумана как средство пыток. Поэтому почти все заявления авиакомпаний будут о том, как удобно и приятно летать, и как вас будут баловать практически на каждом шагу. Когда "Британские авиалинии" (British airways) показали ролик с бизнесменом в кресле самолета, который воображал себя ребенком в коляске, весь здравый смысл улетучился навсегда.
Нужен еще пример? Бумажные компании полностью опустошают наши леса, начисто вырубают растущий лес, который им даже не принадлежит. А когда они дают рекламу, то непременно показывают красивый старый сосновый бор и говорят о своей заботе об окружающей среде. Сигареты приводят к смерти, поэтому их реклама изображает жизнь - со счастливыми улыбающимися здоровыми людьми, упражняющимися на природе. И так далее.
Когда впервые появился Macintosh, не было никакого доступного софта для него. Очевидно, поэтому Apple и создала огромный глянцевый каталог, описывающий прекрасное программное обеспечение, которое было "доступно". Половина пунктов списка мелким шрифтом сообщала: "в разработке", другую же половину было невозможно заполучить ни за любовь, ни за деньги. Некоторые увечные продукты никто бы и не купил вообще. Но даже наличие толстенного глянцевого каталога, на каждой странице которого пылающей прозой было описано отдельное "софтверное изделие", не могло скрыть тот факт, что вы просто не можете купить текстовый редактор или электронную таблицу для своего 128KB Macintosh. Существуют аналогичные "каталоги программного обеспечения" для NeXT и BeOS. (Для фанатов NeXT и BeOS: я не собираюсь пылко обсуждать ваши ничтожные операционные системы, ладно? Пишите свои собственные статьи.) Все, что написано в этих каталогах софта - это то, что не существует софта для вашей системы. Когда вы увидите одного из этих уродцев, бегите в другую сторону.
Amiga, Atari ST, Gem, IBM TopView, NeXT, BeOS, Windows CE, General Magic - это постоянно растущий список "новых платформ", которые провалились. И это произошло потому, что они - платформы, а, по определению, платформы не интересны сами по себе, без стОящих программ, которые бы было можно на этих платформах запускать. Но, за небольшим исключением (я уверен, что получу целую тучу писем от занудных сторонников загадочных и непопулярных платформ типа Amiga и RSTS-11), ни один разработчик программного обеспечения с минимумом здравого смысла не будет намеренно писать софт для платформ с сотней тысяч пользователей в лучшие времена, типа BeOS, когда он может при том же объеме работ создавать программы для платформ с сотней миллионов пользователей, типа Windows. То, что кто-то вообще пишет софт для этих экзотических систем, еще раз доказывает, что корыстные побуждения - это не все, и религиозные предпочтения все еще живы. Как это мило с твоей стороны, дорогой, ты написал симпатичный microEmacs клон для Timex Sinclair 1000. Молодец, возьми с полки пирожок!
Итак, если вы в бизнесе, связанном с разработкой платформ, то, вероятно, вы страдаете от того, что общеизвестно как вопрос о курице и яйце. Никто не станет покупать вашу платформу, пока для нее не будет хорошего программного обеспечения, и никто не станет его писать, пока нет большого количества уже работающих программ. Опа! Это напоминает Гордиев узел, хотя более нагляднее была бы Гордиева спираль смерти .
Вопрос о курице и яйце, а также его вариации - это самый важный элемент стратегии, который нужно понять. Ну ладно, вы проживете и без понимания: Стив Джобс (Steve Jobs) практически сделал карьеру на непонимании вопроса о курице и яйце, причем дважды. Но остальные из нас не имеют в своем распоряжении Личную Систему Искажения Реальности Стива Джобса, поэтому нам придется взяться за работу и тяжело учиться.
Урок первый. Классическая сфера существования вопроса о курице и яйце - software platforms. Но вот другая аналогичная проблема: каждый месяц кредитные компании отправляют клиентам миллионы счетов по почте. Люди выписывают бумажные чеки, вкладывают их в триллионы конвертов и отправляют обратно. Конверты складываются в большие коробки и переправляются в страны с дешевой рабочей силой, где эти коробки открывают, а их содержимое сортируют. Конечная же цена всей этой операции не велика: последняя цифра, которую я слышал, - $1 за чек.
Для нас, ребят, знающих об интернете, это просто какой-то прикол. "Отправьте мне счет по email", - скажете вы и добавите: "Я оплачу его немедленно". Это будет стоить, допустим, одну стотысячную цента, вы же сэкономите миллионы", - ну или что-то в этом роде.
И вы правы. Множество компаний пыталось внедриться в эту отрасль, технически известную как Bill Presentment (выставление счетов). Один пример (угадайте кто) - Microsoft. Решение от Microsoft называется , выглядит это так: веб сайт. Вы туда идете, он показывает ваши счета, вы их оплачиваете.
Итак, если вы получаете свои счета по этой системе от Microsoft, вам необходимо посещать свою страничку каждые несколько дней, чтобы посмотреть, какие счета появились, и вы не пропустите ничего. Если вы получаете, например, 10 счетов в месяц, то никакого особого препятствия пока нет. Здесь есть другая проблема - существует крайне ограниченное количество организаций, которые будут выставлять вам счета через эту систему. Т. е. для оплаты всех остальных приходящих счетов придется податься куда-нибудь еще.
Конечный результат? Оно того не стоит. Я бы удивился, если бы узнал, что 10 000 человек пользуются этой системой в настоящее время. Сейчас Microsoft должен пойти по организациям и сказать: "Высылайте клиентам счета через нашу систему!". А организации ответят: "Хорошо, сколько это будет стоить?", на что Microsoft скажет: "50 центов! Но это ж намного дешевле одного доллара!". А организации спросят: "Хорошо, может что-то еще?", а Microsoft ответит: "Ах да! Это вам обойдется еще примерно в $250 000 - нужно установить программное обеспечение, подключить наши системы к вашим и заставить это все заработать".
И пока у Microsoft совсем немного пользователей, трудно себе представить, что кто-то выложит четверть миллиона долларов, чтобы сэкономить 50 центов на 37 пользователях. Ага! Вопрос о курице и яйце поднимает свою уродливую голову. Клиенты не заинтересуются, пока у вас нет организаций, а организации не заинтересуются, пока у вас нет клиентов! В конце концов Microsoft просто не обращает внимание на эти трудности. Для меньших компаний - это не выход. Что бы сделали вы?
Software платформы, на самом деле, дают нам хорошие советы, как решать проблемы курицы вместе с проблемами яйца. Давайте заглянем чуть-чуть в историю software платформ для персональных компьютеров с момента появления IBM-PC, может, нароем что-нибудь!
Большинство людей считают, что для IBM-PC нужен PC-DOS. Это не так. Когда появился IBM-PC, у вас был выбор между тремя операционными системами: PC-DOS, XENIX (скучнейшая 8-ми битная версия UNIX изданная, и я этого не придумываю, Microsoft), и что-то под именем , которое было, только представьте, как Java: красивое, медленное, с переносимым исполняемым кодом, примерно за 20 лет до Java.
Сейчас большинство людей никогда не слышало про XENIX или извращенский UCSD. Вы, детки, сейчас, наверное, думаете, что это потому, что Microsoft завладел рынком привлекательных операционных систем посредством силы маркетинга или что-то типа этого. Совершенно не верно, Microsoft тогда был крошечным. Компанией с сильным маркетингом тех дней была Digital Research, у которой была другая операционная система. Так почему же PC-DOS выиграл эту гонку?
До PC единственной реально доступной ОС была CP/M, хотя рынок работающих под CP/M компьютеров, которые стоили около $10 000, был очень маленький. Они были слабыми и дорогостоящими, да и не очень дружественными к пользователю. Но те, кто их покупал, делали это для того, чтобы использовать их как текстовые редакторы, потому что можно было заполучить достаточно неплохой текстовый редактор WordStar для вашего CP/M, а Apple II просто не мог использоваться в этом качестве (начнем с того, что у него не было символов в нижнем регистре).
Теперь небольшой известный факт: даже DOS 1.0 был разработан с встроенной обратной поддержкой CP/M. DOS не просто имел новый первоклассный programming interface, известный крепким программистам как INT 21, но и полностью поддерживал старый CP/M programming interface. Под DOS практически могли работать программы для CP/M. Кстати, WordStar перенесли под DOS, изменив один единственный байт кода. (Настоящие программисты скажут что это был за байт, я уже давно забыл).
Это стоит того, чтобы написать еще раз. WordStar перенесли под DOS, изменив один единственный байт кода. Давайте вникнем в это.
Вот здесь.
Получилось?
DOS был популярным потому, что для него был софт с первого дня существования. И для него был софт потому, что Тим Пэтерсон (Tim Paterson) подумал включить поддержку CP/M. Потому, что в эти темные времена кто-то был достаточно умен, чтобы понимать в вопросах о курице и яйце.
Прокрутим вперед. Во всей истории платформы PC, были только два основных примера смены платформы, коснувшиеся почти всех пользователей: мы переключились на Windows 3.x, а потом мы все переключились на Windows 95. Только небольшое количество людей в то время переключились на что-то другое. Заговор Microsoft с целью захвата мира? Хорошо, думайте так. Я думаю иначе, есть другая причина, которая приводит нас обратно к курицам и яйцам.
Мы все перешли на Windows 3.x. Важный момент в этом предложении - это цифра 3. Почему не на Windows 1.0? Или Windows 2.0? Или Windows 286 и Windows 386, которая была потом? Это потому, что у Microsoft заняло 5 релизов "сделать это правильно"? Нет.
Подлинная причина едва различима, она основывается на хитрых возможностях аппаратного обеспечения, которые были впервые представлены в процессоре Intel 80386, требуемый для Windows 3.0.
Первое свойство: когда старые досовские программы печатают на экран, то они пишут напрямую в области памяти, соответствующие позициям на экране. Это был единственный путь сделать вывод достаточно быстрым, чтобы ваша программа выглядела хорошо. Но Windows работал в графическом режиме. На старых интеловских процессорах у инженеров из Microsoft не было другого выхода, кроме как переключиться в полноэкранный режим, когда работали DOS-программы. Но на 80386 они могли установить блоки в виртуальной памяти и прерывания так, чтобы операционная система оповещала, когда программа пытается писать в экранную память. Windows смогла бы немедленно писать соответствующий текст в графическом окне.
Второе свойство: досовские программы предполагали, что они полностью распоряжаются процессором. В результате, они не очень хорошо работали вместе. Но Intel 80386 мог создать "виртульные" компьютеры, каждый из которых действовал как полный 8086, и старые PC программы могли вести себя так, как будто они имеют в своем распоряжении весь компьютер, даже тогда, когда другие программы были запущены и тоже претендовали на весь компьютер.
Итак Windows 3.x на Intel 80386 был первой версией, которая могла многократно запускать DOS программы, ничего не нарушая. (Технически Windows 386 мог выполнять то же, но процессоров 80386 было мало и они были дорогие до того времени, когда как раз появился Windows 3.0). Windows 3.0 был первой версией, которая фактически делала разумную работу по запуску всего вашего старого софта.
Windows 95? Без проблем. Симпатичный новый 32-х битный API, но все еще запускается старое 16-ти битное программное обеспечение. Microsoft преследовал эту цель, потратив целую кучу денег на тестирование всего старого софта под Windows 95, который они только смогли найти. Джон Росс (Jon Ross), который писал оригинальную версию SimCity для Windows 3.x, сказал мне, что он случайно оставил ошибку в SimCity - он читал память, которую только что освободил. Ага. Это хорошо работало на Windows 3.x, потому что память никогда никуда не девалась. Вот удивительная вещь: на бета версиях Windows 95 SimCity не работал при тестировании. В Microsoft отследили ошибку и добавили специальный код к Windows 95, который искал SimCity. Если обнаруживался запущенный SimCity, то распределитель памяти запускался в специальном режиме, в котором память освобождалась не сразу. Вот такая вот навязчивая идея обратной совместимости заставила людей захотеть перейти на Windows 95.
У вас уже должны были появляться идеи о том, как обойти проблему курицы и яйца: предоставлять обратную совместимость либо с развозчиками курей, либо с развозчиками яиц, в зависимости от того, как вы на это смотрите, и вернуться обратно стричь капусту.
А! Теперь назад к выставлению счетов. Помните выставление счетов? Курояйцевая проблема, при которой вы можете оплачивать только счета одной организации, поэтому-то вы и отказались. Microsoft не нашел выхода. Как же вы можете решить проблему? PayMyBills.com и еще с пяток других стартапов из Силиконовой Долины одновременно пытались ее решить. Вы предоставляете режим обратной совместимости: если организация не хочет поддерживать систему, пусть просто посылают свои дебильные бумажные счета на University Avenue, в Palo Alto (там, вероятно, живут студенты, которым не надо много платить, я не знаю - прим. пер.), где куча реальных людей будет открывать их и сканировать. Теперь вы сможете получить все ваши счета на их веб сайте. С того момента, как каждая организация на Земле доступна из вашей системы, клиенты просто счастливы ей пользоваться, даже если она работает в тупом режиме обратной совместимости, в котором какие-то банки, члены платежной системы Visa, электронным путем отсылают счета на принтер, принтер их печатает, потом из вкладывают в конверт, отправляют за полторы тысячи миль в Калифорнию, где конверт разрезают, глупые рекламки, занудно предлагающие "бесплатное" радио AM с часами, которое стоит $9.95, выбрасываются в мусор, а бумажный чек сканируется обратно в компьютер и засылается в веб, куда он должен был быть послан изначально. Но тупой режим обратной совместимости в конце концов исчезнет, потому что PayMyBills.com, в отличие от Microsoft, может реально дать клиентам пользоваться своей системой, и очень скоро ребята из PayMyBills.com смогут пойти к упертым Visa-банкам и сказать: "Эй, у меня есть 93 400 твоих клиентов. Почему бы вам не экономить $93,400 ежемесячно, соединившись со мной напрямую?" И вдруг PayMyBills.com становится очень прибыльной, пока Microsoft все еще тужится подписать на обслуживание вторую электрическую подстанцию, наверное, та, что обслуживает Джорджию, была бы хорошим изменением их темпа развития.
Компании, которым не удается распознать вопрос о курице и яйце могут считаться компаниями по кипячению океана: их бизнес план требует объединения 93 000 000 человек с их сумасшедшими бизнес схемами до того, как это действительно заработает. Одна из самых возмутительно глупых идей, обнаруженных мной, называлась . Их бессмысленный план заключался в том, что каждый человек в мире сможет поставить маленькое дополнение к почтовому клиенту, которое будет искать имена людей на их центральных серверах для получения адресов электронной почты. Потом вместо того, чтобы сказать людям, что ваш адрес kermit@sesame-street.com, вы скажете, что ваш ActiveName "spolsky", и для того, чтобы отправить вам email, им понадобится ставить специальный софт. Бр-р-р. Неверный ответ. Я даже не могу начать перечислять все причины, по которым этот замысел никогда не осуществится.
Заключение: если вы на рынке, которому присущи вопросы о курице и яйце - вам лучше иметь решение с обратной совместимостью, которое растворяет проблему, иначе же, осуществление ваших замыслов может забрать ооочень много времени (в смысле, всё).
Есть много компаний, которые распознают намек на появление вопросов о курице и яйце и умно защищаются. Когда представила свой новый процессор, то она была первой за долгое время не Intel компанией, которая окончательно признала, что если ты делаешь процессоры и хочешь, чтобы огромное количество людей купило твой процессор, то он обязан исполнять x86-код. И это после того, как Hitachi, Motorola, IBM, MIPS, National Semiconductor и кто знает сколько еще компаний обманывали себя в том, что у них есть право придумывать новый набор инструкций. С первого дня принципы Transmeta основаны на том, что любой бизнес план, призывающий делать компьютеры, на которых не запускается Excel, не приведет ни к чему.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
У Microsoft поехала крыша
Автор: Джоэл Сполски
Переводчик: Маргарита Исаева
Редактор: Максим Ромащенко
22 июля 2000
Комментарий автора: эта статья была написана почти за два года до появления .NET, когда рекламный цех Microsoft так разогнался, что почти на два года опередил программный цех. Платформа .NET был настолько разрекламирована, что почти все, что она реально предоставляла, вызывало только разочарование.
Последняя сенсация от Microsoft под названием .NET, превозносимая изданиями типа журнала "Форчун" как грандиозная "революция", на самом деле не что иное как "химерное обеспечение", и доказывает, по-моему, что очень, очень неладно что-то в Рэдмондовском королевстве.
"Химерное обеспечение" означает, что вы обещаете кучу продуктов с возможностями, которые вы не сможете предоставить, потому что у вас их нет. Однако, .NET даже хуже чем "химерное обеспечение". Их вальяжное королевское высочество Microsoft не удостаивает предоставить даже саму химеру.
Прочитайте этот официальный документ внимательно, и вы увидите, что .NET это облако из Страха, Опасениё и Неуверенности. Внутри .NET нет сути. Как ни старайтесь ухватить смысл, переройте весь текст, его там нет. Чем больше вы стараетесь, тем быстрее смысл просачивается сквозь пальцы.
Я не утверждаю, что в .NET нет ничего нового. Я утверждаю, что в .NET вообще ничего нет.
Поcмотрите на это:
Все согласятся с тем, что Веб будет развиваться, но чтобы это развитие открывало подлинно новые перспективы для поставщиков программного обеспечения, производителей и потребителей, нужно радикально новое видение. Цель компании Microsoft — предоставить такое видение, а также технологию, позволяющую претворить это видение в жизнь. ["Microsoft .NET: Реализуя следующее поколение", Июнь 2000].
Как насчет:
Видение Microsoft .NET означает новые возможности для потребителей, производителей, поставщиков программного обеспечения и для всей отрасли. Это означает подлинное развертывание всего потенциала Интернета. И это означает, что Веб будет таким, каким вы хотите его видеть. [Там же]
Что происходит? Во всей статье я не смог найти ни одной идеи, которая могла бы быть реализована как программный продукт. Вместо того, чтобы предоставить список функций, Microsoft дает список расплывчатых "преимуществ", как например:
Веб сайты становятся гибкими Веб сервисами, которые могут взаимодействовать и обмениваться данными на взаимовыгодной основе. [Там же]
Вот он, краеугольный камень революционной .NET архитектуры. Тот факт, что все сформулировано в таких неопределённых общих выражениях, что не значит вообще ничего, по-видимому, никого не беспокоит. А вот еще:
Microsoft .NET делает возможным нахождение сервисов и партнеров для последующего сотрудничества. [Там же]
Вот радость-то! Через пять лет после того, как заработала Altavista, и через два года после того, как Ларри Пейдж (Larry Page) и Сергей Брин (Sergei Brin) создали , Microsoft делает вид, что в Интернете ничего найти нельзя, и они решат эту нашу проблему. И так весь документ.
Происходят две вещи. В Microsoft есть большие мыслители. Когда эти мыслители размышляют над проблемами, они находят в них что-то общее. Они смотрят на то, как пользователи посылают друг другу файлы в формате текстовых процессоров, на то, как другие пользователи посылают друг другу электронные таблицы, и замечают общее: посылка файлов. Это первый уровень абстракции. Дальше они поднимаются уровнем выше: пользователи посылают файлы, но и броузер " посылает" запросы на веб страницы. Это всё операции посылки, так что наши мыслители придумывают еще одну, большего радиуса поражения абстракцию, под названием посылка сообщения, но теперь это становится совсем туманным, и теперь никто не понимает, о чем вообще идет речь.
Если вы совершаете восхождение на г. Абстрактная и заходите слишком далеко, вам начинает не хватать кислорода. Иногда мощные умы просто забывают, что пора остановиться, и создают эти причудливые, всеохватывающие, высокоуровневые модели вселенной, которые сами по себе прекрасны, вот только не значат ровным счетом ничего.
Похоже, так и произошло.
Новое поколение настольных Windows платформ, Windows.NET, позволяет повысить продуктивность, креативность, управляемость, развлекательность и многое другое, и призвано позволить пользователям управлять их цифровым существованием. [Там же]
Все это настолько абстрактно, что ниже всякой критики. Кто же не хочет операционную ситему, которая повышает продуктивность? Отличное качество! Дайте-ка мне одну из этих новых, классных операционных систем со свойством "продуктивность"! Вопрос: как Microsoft собирается этого добиться? За последние 20 лет истории программного обеспечения, повышение продуктивности шло медленно, но верно. Может быть они открыли новый химический элемент, который сделает их операционную систему более продуктивной? Я так не думаю. Я думаю, они блефуют. Страх, Опасения, Неуверенность и "химерное обеспечение".
Самое страшное, они это — всерьез.
Я знаю Microsoft; работал там три года. Я знаю что за люди писали этот документ. Почти наверняка большая роль принадлежит Биллу Гейтсу; он для того и ушел с поста директора — чтобы работать над этим проектом. Я не думаю, что в Microsoft сочинили этот текст потому, что им понадобилось "химерное обеспечение". Там работают очень умные люди.
Я полагаю, они действительно верят в то, что создают будущее, и что они знают, как это делается. Они изучили все свои продукты, от Hotmail до SQL Server, и попытались вписать их в Новое Революционное Видение. Беда в том, что никто там не изобретает ничего революционного. Что и неудивительно, и не потому что Microsoft глупа, вовсе она не глупа, а потому, что революционные изобретения очень редки, а у Microsoft только конечное число интеллектуалов. Один человек во всем мире придумал Napster, и он не работал на Microsoft. Microsoft отчаянно хочет верить в то, что она — фабрика революций, но даже в период Кембрийского взрыва Интернета, в год появляется лишь горстка действительно революционных идей, и шансы на то, что одна из них родится в крохотном мирке Билла Гейтса и рыцарей Редмондского стола исчезающе малы. Шансы станут еще меньше, если учесть, что рядовой талантливый программист, работающий в недрах Microsoft над драйвером дисплея для Windows NT, которому пришла на ум великолепная идея, скорее всего, не будет услышан.
Единственное, что можно понять из статьи, это то, что программы вы будете получать по подписке через Интернет, а не инсталлировать с CD.
Возможно, для потребителя получение текстового процессора по подписке через Интернет действительно небольшое удобство, хотя... да нет, я бы не сказал. Это не решает ни одной реальной проблемы. Ошибки будут исправляться через Интернет? Здорово. Я и сейчас могу это делать. Я скачиваю патчи к Microsoft’овским программам уже 7 лет, и процесс этот почти автоматизирован. Получение новых версий? Так в чем смысл, если новая версия не делает ничего нового, кроме того, что облегчает получение новых версий! В последних трех версиях в Word не было добавлено ни одного нового свойства, только однажды было придумано нечто фантастическое для облегчения позиционирования картинок, так что теперь мне в жизни не поместить картинку, куда я хочу.
Правда в том, что еще в 1991 году Microsoft заметила, что все увеличивающаяся доля доходов приходит от апгрейдов, и что заставить всех и каждого апгрейдиться трудно, и они уже почти десять лет пытаются уговорить потребителей на покупку программ по подписке. Не получалось — потребители не хотят. Microsoft видит .NET как способ наконец-то навязать модель подписки, которая отвечает их конечным целям.
Похоже на то, что .NET не удовлетворила ни одной потребности пользователей, а только потребность самой Microsoft чем-то занять 10,000 программистов в течение последующих 10 лет. Мы все знаем, сколько воды утекло с тех пор, как было придумано последнее новшество для текстового процессора, от которого действительно была бы польза, так чем же прикажете заниматься всем этим программистам?
Светлая сторона "Видения"
Анекдот с бородой: человек приходит на прием к психиатру. Тот показывает ему картинку с птичкой и спрашивает "Ну-с, батенька, и о чем мы думаем, глядя на эту картинку?" Человек отвечает: "о бабах" Психиатр достает картинку с деревом. "Ну хорошо, а глядя на эту картинку?" Человек отвечает: "о бабах". Картинка с поездом. "О бабах." Дом. "Да о бабах же!"
- "Боже мой!" — восклицает психиатр. "Да вы помешаны на сексе!"
- "Я помешан на сексе!?" — изумляется человек. "Это вы мне целый час неприличные картинки показываете!"
Чтоб вы знали: светлая сторона темных документов, таких как статья про .NET, они работают как тест Роршаха. Их читают с определенным идеями в голове, а так как документ достаточно темен и туманен, думают что Microsoft озвучивает их идеи. Дейв Винер (Dave Winer), президент UserLand software, предложил много интересных, инновационных идей. Читает он про .NET и видит, что до Microsoft наконец-то дошло то, о чем он говорит вот уже два года. Дейв, ты слишком хорошо о них думаешь. По сравнению с тобой они полная темнота. Они используют прием гадалок по телефону и газетных гороскопов: скармливают тебе бессмысленные общие места и заставляют поверить, что читают твои мысли. "Сегодняшнее расположение планет говорит о том, что вы сделаете большой шаг вперед в реализации своих целей." Разница в том, что у Дейва реальные, конкретные идеи, которые можно воплотить в реальные программы, а Microsoft — все в той же стране чудес, где была шесть лет назад, когда она трубила о том, что "Cairo" предоставит "Информацию На Кончиках Ваших Пальцев", — обещание, которое выполнил Интернет, и не выполнил Cairo.
Будем надеяться, все эти бессмысленные "ля-ля" вдохновят кого-нибудь на реальные новшества (как это было в UserLand). Но эти новшества придут скорее извне Microsoft, чем из нее.
Постскриптум: "Подождите, — скажете вы. — Но у меня же есть .NET SDK!"
После того, как эта статья была опубликована, многие мне написали с тем, чтобы сказать, что у них есть .NET SDK! Он не химера! Он "настоящий!"
Эээ... Хм... Ну да. Так что там в нем? А там SOAP, технология, разработанная Дейвом Винтером на базе XML-RPC, и которую я использовал для регистрации пользователей на сайте компании Juno примерно два года назад. Microsoft немного опоздала к этому пирогу. Там язык программирования, C#, с помощью которого Microsoft заявляет, что если уж мы не можем прибрать к рукам Java, черт бы её побрал, то мы пошли домой играть в свои игрушки. Там новые версии ADO, ASP, и чего-то еще... очень хорошего, но это все-таки лишь постепенное улучшение. К сведению журнала "Форчун": там нет ничего революционного. Не работай маркетинговая машина Microsoft в режиме перегрева, мы бы получили все то же самое, только никто бы не притворялся, что это компьютерная нирвана замаячила на горизонте.
Вот так Microsoft и работает: на каждый продукт у них своя группа разработчиков, и каждый год-другой эта группа выпускает в свет новую версию своего продукта. Вот и все. И имеем мы тут, леди и джентльмены, чисто маркетинговую команду, которая посмотрела на все готовящиеся новые версии, решила, что им нужна "тема", чтобы Microsoft выглядела Великим Изобретателем и Рационализатором, и постановила: отныне звать всем свой очередной шедевр ".NET". Когда вы работаете в таком месте, как Microsoft, ничего нет хуже людей маркетинга у руля: читайте этот отклик, написанный сотрудником Microsoft.
В английском оригинале статья называется Microsoft Goes Bonkers
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Верблюды и песочница
Автор: Джоэл Сполски
Переводчик: Егор Егоров
Среда, 15 декабря 2004
Вы только что выпустили программное обеспечение для организации фотоальбомов. Оставим вам на домашнее задание маркетинговый вопрос, мы предполагаем, что люди как-то узнали о вашем продукте. Может быть, у вас есть популярный блог или еще что-то. Может быть Уолт Моссберг написал небольшой мутный обзор вашей программы в Wall Street Journal.
Один из самых серьезных вопросов, который вы должны задавать себе сейчас, это «Сколько должна стоить моя программа?». Когда вы спрашиваете об этом финансовых специалистов, то выходит, что они этого не знают. Ценообразование — это большая и таинственная наука, скажут они вам. Самая большая ошибка, которую совершают софтверные компании — они ставят заниженную цену для своего программного обеспечения. Это приводит к тому, что они недополучают свою прибыль и в итоге вынуждены покинуть бизнес. А еще большая ошибка... Да, гораздо большая ошибка — это ставить слишком высокую цену. Потому что они недобирают себе клиентскую базу и снова-таки вынуждены покинуть бизнес. А уходить из бизнеса — это не есть хорошо, поскольку все теряют работу, ну а вам приходится идти в ближайший супермаркет работать кассиром. При этом ваш доход минимален, и вы целый день носите синтетическую униформу.
Так что если вам больше нравится трикотаж — вам лучше вникнуть в обсуждаемый вопрос.
Ответ на самом деле довольно сложен. Я начну с короткого рассказа об азах экономической теории, затем я разложу теорию по полочкам. Когда я закончу — вы будете иметь гораздо более полное представление о ценах, но все равно не будете знать, сколько же вам брать денег за свое программное обеспечение. Ну просто такова природа ценообразования. Если вы не хотите заморачиваться на этом вопросе — требуйте $0.05 за вашу программу, если она не предназначена для багтрекинга. В последнем же случае она должна стоить $30,000,000.
Итак.
Немного экономической теории.
Представьте себе на секундочку, что ваша программа стоит $199. Почему $199? Просто я должен откуда-то начать. Мы скоро будем рассматривать другие цифры. Но сейчас пока будем исходить из того, что программа стоит $199 и что по такой цене ее берут 250 покупателей.
Я нарисую:
Этот небольшой график показывает, что если ПО стоит $199 — 250 человек купят его. (Как видите, экономисты довольно странные люди, и они предпочитают положить количество продаж на ось X, а стоимость продукта на ось Y. Если бы 250 человек купило вашу программу, это должно означать, что вы получили за нее по $199).
Что произойдет, если вы поднимете цену до $249?
Некоторые люди, что были готовы платить $199 решат, что $249 — это слишком дорого, и откажутся от покупки.
Те же покупатели, что не были готовы отдать за продукт сумму в $199 — разумеется, не купят его и за $249.
Если 250 человек купили продукт за $199, мы должны понимать, что за $249 его купит меньшее количество покупателей. Скажем, ну, человек 200:
А что, если бы мы установили меньшую цену? Например, $149? Ну тогда все те, кто готов был купить его за $199, разумеется, купят его и за $149. Даже больше будет тех людей, что сочтут эту цену более привлекательной, так что мы продадим, скажем, 325 копий по цене $149:
И так далее:
Здесь скорее нужно изобразить кривую, проходящую через все эти дискретные точки:
Теперь вы называете мне любую цену от $50 до $400 и я скажу вам, сколько человек купит вашу программу по этой цене. Что мы сейчас нарисовали - это классическую кривую спроса. Кривая спроса всегда стремится на спад, поскольку чем дороже продукт, тем меньше желающих его приобрести.
Эти цифры, конечно, взяты с потолка. Поверьте мне пока только в одном: кривая спроса всегда ниспадает.
Он, наверное, сейчас ведет блог.)
Так сколько же вы должны брать за вашу программу?
«Ну, $50, поскольку тогда я продам больше всего копий!»
Нет-нет-нет. Перед вами ведь не стоит задача максимизировать количество продаж, перед вами стоит задача максимизировать прибыль.
Давайте посчитаем прибыль.
Будем считать, что каждый продаваемый экземпляр программы обоходится вам в дополнительных $35.
Может быть, разработка ПО стоила вам в $250,000, но это т.н. невозвратные капиталовложения, первоначальные затраты. Нас больше не интересуют эти деньги, потому $250,000 — это $250,000, продадите вы 1000 экземпляров или 0. Невозвратные. Попрощайтесь с ними, помахайте ручкой. Поставьте любую цену, но $250,000 ушли и поэтому больше не играют никакой роли.
На этом этапе все, что нас может беспокоить — это стоимость продажи каждой дополнительной
копии, маргинальная стоимость. Она может включать в себя доставку, техническую поддержку, стоимость банковских услуг, стоимость физического носителя — да что угодно. Я буду использовать сумму в $35 в качестве маргинальной стоимости.
Итак, теперь мы запускаем замечательные электронные таблицы:
мы берем $399, то в этом случае мы продаем 12 копий, получая с каждой прибыль в $364, что в сумме дает нам $4368 прибыли.
ЭТО УЖЕ ЧТО-ТО!
Это действительно здорово. Я думаю, мы сейчас приближаемся к тому моменту, когда мы точно знаем столько брать за наш продукт. Я ТАК ВОЛНУЮСЬ!
И вот почему. Если мы нарисуем график цены относительно прибыли, то мы получим красивую кривую с большим горбом посередине. И все мы знаем, что такое горб. Горб — это вершина кривой, локальный максимум! Или верблюд. Но сейчас нам важно считать, что горб — это локальный максимум.
В этом графике реальные данные изображены как маленькие голубые бриллианты, и я попросил Excel нарисовать красивую полиномную линию тренда поверх них.
Все что мне остается сделать — это опустить прямую линию вниз с вершины кривой, и я узнаю цену, продавая по которой, я смогу получить максимальную прибыль:
«Сегодня волшебный день!!! Аллилуйя!!», кричу я. Мы нашли оптимальную цену, $220, и вот это точно та цена, по которой вам следует продавать ваше ПО.
Отлично.
Спасибо за внимание! Семинар закончен, вы можете расходиться.
Вы все еще здесь?
Понимаю.
Некоторые наиболее внимательные читатели с помощью всестороннего анализа полосы прокрутки веб-броузера уже обнаружили что мне, пожалуй, еще есть чего сказать, чего-то большего, чем просто «$220».
Ну что же, может быть. Есть еще одно небольшое замечание, которое вы позволите мне сделать, хорошо? Хорошо.
Понимаете... вот мы продали, скажем, 233 копии программы по цене $220 и получили общую прибыль в $43,105. В принципе, это все чудесно, но меня что-то беспокоит. Те люди, что были готовы заплатить больше, ну как вот эти 12 персон, что отдали бы $399 — заплатили все те же $220, как и все остальные!
Разница между $399 и $220, а это $179, называется выгода потребителя (consumer surplus). Это вот как раз та сумма, которая остается на руках богатых потребителей в виде выгоды, прибыли, с которой они вообще-то были бы счастливы расстаться.
Это как если бы вы планировали купить теплый и уютный шерстяной свитер. Вы предположили бы, что он стоит $70, что, в принципе, звучит разумно. Затем, попав на распродажу в Банановой Республике — вы обнаруживаете, что свитер стоит всего $50. Теперь у вас есть лишние $20, которые, в принципе, вы были совсем не прочь отдать банановцам.
Во как!
Это раздражает хороших капиталистов. Елки-палки, если ты хочешь расстаться с $20 — отдай их мне! Я могу ими правильно распорядиться, купив мерседес, яхту или любую другую из тех вещей, что обычно покупают буржуи.
На экономическом жаргоне это означает что мы хотим захватить выгоду потребителя.
Давайте поступим следующим образом. Вместо того, чтобы брать $220, давайте спросим каждого покупателя, богат он или беден.
Если они скажут, что богаты — мы будем выставлять счет на $349. Если они бедны — то на $220.
Тогда сколько мы получим? Снова в Excel:
Дайте мне побольше этой вот выгоды потребителя!
Однако стоп, это еще не все. После того, как я продал эти 233 копии, я как-то неловко почувствовал себя перед теми людьми, что хотят заплатить всего $99. В конце концов, если бы я мог продать еще некоторое количество экземпляров этим перцам по $99, я бы все равно сделал деньги, поскольку у меня маргинальная стоимость — это всего лишь $35.
Что если бы мы позвонили всем покупателям, что сказали «нет, спасибо» цене в $220 и предложили бы им ПО за $99?
На такую цену в $99 у нас есть 450 потенциальных покупателей, и не забывайте, что 233 из них уже заплатили полную цену. Итого у нас есть еще 217 дополнительных потребителей, что просто не могут позволнить себе заплатить полную цену:
Мамамояродная, у меня есть подозрение, что мы только что срубили $62k прибыли! В конце концов, еще двадцать тыщ бабла! И все это - благодаря сегментированию: разделению покупателей на разные категории в зависимости от того, сколько они готовы платить, и забирая максимальную выгоду каждого покупателя. Сегментирование. Братан, сколько б мы заработали, если бы могли заставить каждого покупателя сказать нам, сколько же они максимально готовы заплатить, и брать именно эту сумму?
Невероятно!! Почти $80k. Это практически в два раза больше, чем прибыль, что извлекается из единой цены. Загребать выгоду потребителя однозначно прибыльно. Даже те 350 доставучих покупателей, желающих получить мою программу за $49 - приносят мне какую-то прибыль. И все эти потребители счастливы, потому что мы предлагаем им заплатить ту цену, которую они уже готовы платить, так что мы не оббираем их. Ну, типа.
Вот несколько примеров сегментации, с которыми вы безусловно знакомы:
Скидки пенсионерам: пожилые люди живут на «фиксированном доходе», и готовы платить меньше, чем работоспособные. Дешевые дневные кинопоказы (поскольку на них ходят безработные). Авиарейсы, где, похоже, каждый пассажир платит свою цену. Тихий секрет про ценовую политику авиакомпаний заключается в том, что люди, летающие по делам, получают свои билеты от компании, отправляющей их в командировку, и поэтому им безразлично, сколько стоит билет. В это же время частные путешественники тратят свои собственные деньги и они не полетят, если это будет стоить слишком много.
Разумеется, авиалинии не могут просто спросить вас, путешествуете ли вы по делу или нет, потому что в скором времени все разгадают этот секрет и станут обманывать, чтобы летать дешевле. Но сотрудники, как правило, летают по будним дням, и они терпеть не могут
проводить выходные вдали от дома. Поэтому авиалинии ввели правило, что если вы остаетесь на ночь субботы, то вы, скорее всего, путешествуете не в командировке. Поэтому они дадут вам цены гораздо лучше, если вы остаетесь на ночь субботы.
Есть еще более тонкое сегментирование. Знаете вот эти купоны на скидку, что публикуются в газетах? Ну, те, что дадут вам 25 копеек скидки с коробки стирального порошка, если вы вырежете их из газеты и не забудете принести с собой в магазин? У этих купонов есть определенная особенность. С купонами связано слишком много трудозатрат — вырезать их из газеты, сортировать, сохранять, запоминать, выбирать бренды исходя из имеющихся купонов. В результате эффект от купонов таков, что если вы вырезаете купоны — то вы работаете за $7/час (очень низкая зарплата в США — прим. пер.)
В принципе, если вы вышли на пенсию, то $7 в час - это звучит неплохо, и вы будете вырезать купоны. Однако если вы аналитик на бирже, получающий $12,000,000 в год за то, что говорите лестные слова про паршивые интернет-компании, то работа за $7 в час — это шутка, и вы не будете вырезать купоны. Так что купоны — это один из способов сегментировать рынок потребительских продуктов. Сертификаты на скидки, которые вы получите, если отправите письмо с запросом в магазин — это примерно тоже самое, с некоторыми отличиями в том, например, что они узнают ваш почтовый адрес, чтобы доставать вас в будущем.
Существуют другие способы сегментировать рынок. Вы можете предлагать ваш продукт под разными торговыми марками («Old Navy», «The Gap», «Банановая Республика») и предполагать, что богатые люди будут помнить, что одежду следует покупать в Банановой Республике, в то время как бедные пойдут в Old Navy. А для того, чтобы избежать риска, что люди позабудут про свой статус и пойдут не в тот магазин — Банановая Республика сверкает своими дорогими огнями в районе, где полно жалких лачуг местных богатеев средней стоимостью в $2,000,000. А Old Navy расположен возле вокзала, куда ты несешь свой уставший зад домой, в Нью Джерси, после зверски утомительного физического труда на работе.
В мире ПО вы можете просто выпустить версию вашего продукта под названием Professional и еще одну версию под названием Home. Определив между ними незначительные различия и надеяться, что корпоративные покупатели (повторяю — те, кто тратят чужие деньги) почувствуют себя неудобно, используя «Windows XP Home Edition» на работе и они купят Pro версию. Домашняя версия в офисе? Да они б еще в пижаме додумались на работу приходить, охламоны.
Простой трюк: если вы хотите развернуть сегментирование, то лучше предложите скидку для определенных пользователей, чем премиум тариф для других. Никто не хочет почувствовать что его обобрали: люди скорее купят за $99 продукт, стоящий $199, чем $59-ый продукт за $79. Теоретически, люди должны мыслить рационально. $79 это меньше чем $99. Однако на практике они терпеть не могу чувствовать, что кто-то на них наживается. Им гораздо больше нравится успешно сторговываться с вами, чем покупать »особую версию».
ТАК ИЛИ ИНАЧЕ.
До этого момента все было просто.
А вот сложность заключается в том, что все, что я выше сказал — несколько неправильно.
Люди хотят думать, что платят реальную цену. Им не нравится думать, что они платят лишние деньги лишь потому, что они недостаточно умны, чтобы найти волшебный купон. Индустрия авиаперевозок настолько преуспела в сегментировании, что дает свою цену буквально каждому пассажиру. В результате, многие люди почувствовали, что они не получают наилучшее предложение и возненавидели авиалинии. И когда появилась альтернатива в виде дешевых локальных авиалиний, вся лояльность пассажиров исчезла. (в СНГ такую роль сыграли чартерные авиарейсы -- прим. пер.)
И сохрани вас Господь, когда популярный блоггер обнаружит, что ваша дорогая модель принтера в точности идентична дешевой, но специально «замедленной» по производительности.
Так что если сегментирование может быть полезным для получения выгоды потребителя, оно может также иметь негативные последствия для имиджа вашего продукта в далеком будущем. Многие разработчики ПО обнаружили, что их прибыль пошла на подъем, а количество торгующихся потребителей пошло вниз, когда они избавились от купонов, скидок, множественных версий и прослоек. Получается, потребителям больше нравится платить $100 когда все вокруг платят $100, чем платить $79 когда они знают, что кто-то еще получает этот продукт за $78. Да что там, General Motors создали целую автомобильную компанию, основав ее на принципе, что предложенная цена справедлива и вы не будете торговаться.
Даже исходя из того, что вы готовы к долгосрочной перспективе проржавения потребительской лояльности, вызванной вульгарной ценовой дискриминацией, сегментация все равно не так проста. В первую очередь, как только ваши покупатели поймут, что вы сегментируете их по ценам, они начнут вас обманывать насчет того, кто они есть:
Часто путешествующие в командировку специалисты будут брать билеты с двойной субботней ночевкой. Например, консультант, живущий в Питтсбурге и работающий в Сиеттле с понедельника по четверг, купит двухнедельное пушествие из Питтсбурга в Сиеттл, и затем билеты на уикенд на середину. Оба путешествия включают в себя ночевку на субботу, это те же самые самолеты, но в итоге все вместе получается дешевле. Даете академическую скидку? Каждый, кто отдаленно имеет какое-то отношение к кому-то, отдаленно
связанному с образованием — будет требовать эту скидку. Если пользователи общаются между собой, то они обнаружат, что платят разные цены, и вам придется для всех снизить цену до минимальной прозвучавшей. Особенно для больших корпораций, которые теоретически должны проявлять самый высокий уровень «готовности платить». У корпораций есть специальные департаменты закупок, где люди получают зарплату за то, чтобы закупать по самым выгодным ценам. Эти люди ходят на конференции, где они учатся требовать себе наилучшие цены. Они целый день перед зеркалом
тренируются произносить «Нет. Дешевле.» Ваш парень, занимающийся продажами, не имеет ни малейших шансов.
Есть две формы сегментации, практикуемые пронырливыми компаниями-разработчиками софта, и которые реально являются не такими уж хорошими идеями:
Плохая идея #1: Безлимитные лицензии (Site Licenses).
Противоположность сегментации. Правда. У меня есть некоторые конкуренты, практикующие следующее. С небольших клиентов они берут оплату по количеству пользователей системы, и в то же время существует «неограниченная» лицензия по фиксированной цене. Это глупо, потому что вы даете шикарную скидку именно крупнейшим покупателям. Как раз именно тем, кто готовы заплатить вам наибольшие деньги. Вы действительно хотите, чтобы IBM купило ваше ПО для своих 400,000 сотрудников и заплатило вам $2,000? Дааа?
Как только у вас появится «неограниченная лицензия», вы сразу отдаете гигантский объем потребительской выгоды в дар как раз именно тем наименее чувствительным к цене компаниям, кто должен стать дойной коровой вашего бизнеса.
Плохая идея #2: Сколько у вас денег? Ценообразование.
Эта идея была использована в компаниях, созданных экс-менеджерам Oracle, там, где цены нет нигде на веб-сайте. Неважно, сколько вы потратили на поиски. Все, что вы найдете - это форма, где вас просят оставить ваше имя, адрес, номер телефона и факса, хотя отправлять факсом они вам совершенно ничего не собираются.
Очевидно, что их план — это натравить на вас менеджера по продажам, задачей которого будет выяснить у вас, сколько вы стоите и выставить вам счет на адекватную сумму. Идеальная сегментация!
Тем не менее, оно хорошо не работает. В первую очередь, бюджетные покупатели пройдут мимо, поскольку они решат, что если цена не указана на вебе — то она высока и они ее «не потянут». Во-вторых, люди, не терпящие насилия со стороны менеджеров по продажам также исчезнут с горизонта.
Хуже. Как только вы посылаете сигнал, что ваша цена обсуждаема, вы получите обратное сегментирование. Вот почему. Большие комании, которым вы продаете, те, кто должен давать вам больше всего денег, вот они как раз невероятно грамотны в вопросах закупок. Они поймут, что ваш менеджер по продажам работает на комиссионных, и они знают, что у него есть квартальный план. И они знают, что и он сам, и его компания будут крайне рады сделать продажу в конце квартала (чтобы менеджер получил свою комиссию, а компания избежала расправы инвесторов). Так что большие корпорации всегда будут ждать до последнего дня квартала, чтобы получить неприлично низкую цену, и они вовлекут вас в финансовую интригу, заставив думать о заоблачных прибылях, которые вы никогда на самом деле не получите.
Так что не надо предлагать неограниченные лицензии и не надо создавать цену на ходу.
СТОЯТЬ!
Действительно ли вы хотите максимизировать прибыль? Я что-то упустил. Вы ведь на самом деле не сильно беспокоитесь о прибыли в этом месяце. В действительности вы переживаете за прибыль как таковую, включая также и будущую. Выражаясь формально, вы хотите увеличить NPV (чистую приведенную/современную стоимость) денежного потока всех будущих прибылей (даже не допуская уровень наличного резерва ниже нуля).
Диверсификация: Что такое NPV?
Что стоит больше, $100 сегодня или $100 через год?
Очевидно, $100 сегодня, потому что вы можете инвестировать их, скажем, в ценные бумаги и в конце года у вас будет около $102.25.
Так что если вы собираетесь сравнивать стоимость $100 через год и $100 сегодня, вам нужно дисконтировать эту сумму на процентную ставку. Если процентная ставка составляет, скажем, 2.25%, то эти будущие $100 должны быть оценены в $97.80, что называется чистой приведенной стоимостью
(чистой современной стоимостью, Net present value, NPV) $100 через один год.
Чем дальше в лес — тем сильнее вам следует дисконтировать эти $100. $100 через пять лет, по текущим процентным ставкам, стоят только $84 сегодня. $84 — это чистая приведенная стоимость $100 через пять лет.
Сколько бы вы предпочли заработать?
ВАРИАНТ НОМЕР ОДИН:
$5000, $6000, $7000 в течении следующих трех лет
ВАРИАНТ НОМЕР ДВА:
$4000, $6000, $10000 в течении следующих трех лет
Вариант номер два звучит вроде как выгоднее, даже если дисконтировать будущие прибыли. Если вы берете вариант номер два, то получается что вы инвестируете $1000 в первом году и получаете $3000 через три года, что, в общем, выгодно.
Причина, по которой я поднимаю этот вопрос, заключается в том, что ценообразование программного обеспечения раскладывается на три планки: бесплатно, дешево и экстремально.
Бесплатно. Open source и т.п. Не относится к нашей дискуссии. Ничего интересного. . Дешево. По стоимость $10 — $1000, продающееся большому количеству покупателей по низкой цене, даже без отдела продаж. Большинство потребителей и небольших бизнесов попадают в этот рынок. Эстремально. ПО стоимостью $75,000 — $1,000,000, продающееся небольшому количеству богатых компаний с помощью команды свирепых сейлсов, шесть месяцев кряду издевающихся над просто чтобы создать одну продажу. Модель Oracle.
Все три метода работают.
Обратили внимание на промежуток? Нет программ стоимостью между $1000 и $75,000. Я объясню, почему. Как только вы переходите барьер в $1000, вам нужна серьезная работа с корпорациями. Вы метите на позицию, занимающую целую строчку в их бюджете. Вам нужны контакты с менеджерами по закупкам и утверждение приобретения высшим руководством, а также конкурентоспособность в тендерах и масса бумажной работы. Вам потребуется отправить в ту корпорацию профессионального менеджера по продажам, вооруженного PowerPoint'ом, вместе с его бизнес-классом в самолете, членством в гольф-клубе и порнофильмами по $19.95 в отеле Ritz Carlton. Со всем этим, стоимость одной успешной продажи будет в среднем $50,000. Если вы командируете такого профессионала и берете меньше чем $75,000 — вы теряете деньги.
Самое смешное, что большие компании настолько серьезно оберегают себя от дорогих покупок, что они на практике взвинчивают стоимость дорогого ПО с $1000 до $75000. Большая часть этих денег идет на обслуживание всех примочек, которыми они пользуются во избежание дорогих покупок.
Так вот, короткий взгляд на показывает, что я нахожусь четко на планке номер два. Почему? Продажа софта по низкой цене означает, что я получаю тысячи клиентов сразу. Кто-то большой, кто-то нет. И все эти люди будут использовать мой софт, и рекомендовать его своим друзьям. Когда эти клиенты вырастут, они купят больше лицензий. Когда люди, работающие в этих компаниях, перейдут в другие, они будут советовать мой софт новому коллективу. Т.е. я соглашаюсь на низкую цену в обмен на подготовку почвы для будущих продаж. Я рассматриваю низкую цену FogBugz как инвестицию в рекламу, отдачу с которой я предполагаю получить гораздо позже. Пока что эта схема работает замечательно: продажи FogBugz выросли более чем на 100% за три года без маркетинговых усилий, исключительно на устных рекомендациях людей и на росте количества лицензий у существующих клиентов.
Для сравнения давайте возьмем BEA. Большая компания. Высокая планка цены. Да эта цена сама по себе означает, что практически никто не работал с их продуктом. Никто не выходит из института и не стартует новый бизнес с технологией BEA, потому что они не могли позволить себе BEA в институте. Множество других замечательных технологий похоронили себя в высоких ценах: Apple WebObjects не рассматривался как сервер приложений, потому что его цена начиналась с $50,000. Кого волновало, насколько он хорош? Никто его даже и в глаза не видел. Все, что создано в Rational. Единственный способ, благодаря которому эти продукты попадают в руки пользователей — это под мощной атакой специалистов по продажам. По такой цене продажи ведутся в направлении исполнительных директоров, а не технических специалистов. Технари могут настолько эффективно противостоять гадостным технологиям с высококлассными менеджерами по продажам, что исполнительные директора в конце концов заткнут им рты. У нас предостаточно клиентов, пользующся FogBugz в то время как они уже имеют один из жутко дорогих продуктов Remedy, Rational или Mercury, лежащих на полочке после $100,000-ых вложений лишь потому, что это ПО элементарно неудовлетворительного качества и не подлежит эксплуатации. Потом они покупают FogBugz за пару тыщ, и это именно тот продукт, который они реально используют. Менеджер по продажам компании Rational смеется мне в лицо, потому что у меня $2000 в банке, а у него $100000. Но у меня куда больше клиентов, чем у него, и все они пользуются моим ПО, и агитируют за него и распространяют его, в то время как клиенты Rational либо (a) не используют его или (b) используют его и их тошнит. Однако он смеется мне в лицо со своей 40-футовой яхты в то время как я играюсь в песочнице. Как я сказал, все три метода работают. Но низкие цены — это покупка рекламы и как таковая является инвестицией в будущее.
Хорошо.
О чем это я.
Ну да. Предже чем у меня пошла пена изо рта, я как раз рассуждал о кривой спроса. Когда я провел вас через всю эту дискуссию, вы наверняка задавали себе вопрос: «Как же я узнаю, сколько люди готовы платить за мой софт?»
Вы правы.
В это-то и проблема.
Вы не можете на самом деле построить кривую спроса.
Вы можете собрать фокус-группы и спрашивать людей, но они вам соврут. Некоторые люди будут врать, чтобы показать свою щедрость и состоятельность. «Без базара, я куплю пару джинс за $400 в New York Minute». Другие будут врать, потому что они действительно нуждаются в вашей штуке и они подумают, что вы снизите цену, если они вам назовут планку пониже. «Софт для блоггинга? Хмм.. я заплачу не более .»
Затем вы спросите другую фокус-группу на следующий день. В этот раз первый заговоривший захочет произвести впечатление на красавицу, также участвующую в фокус-группе, и он начнет рассказывать о том, какая у него дорогая машина, и все подумают о Больших Цифрах. А через день вы приглашаете участников попить кофе в кафе во время перерыва, и этот человек отведет вас в сторонку, вовлечет в переговоры о том, чтобы заплатить $4 за его кофе, и ему в действительности будет очень депрессивно с вами говорить на эту тему, особенно когда вы-таки попросите его заплатить за себя самому.
Затем вы в конце концов доведете фокус-группу до момента, когда все согласятся, что ваш софт стоит $25 в месяц, а когда вы спросите, сколько они бы заплатили за бессрочную лицензию, те же самые люди не дадут вам ни цента больше $100. На самом деле, люди не умеют .
Или вы спросите авиаконструкторов, сколько бы они заплатили и выведете максимальную цифру в районе $99, хотя авиаконструкторы с легкостью каждый день пользуются софтом стоимостью более $3000 в месяц, даже не зная об этом. Потому что решения о покупке принимают совсем другие люди.
Так что день ото дня вы будете получать совершенно, да, я хочу сказать совершенно
разные ответы на вопрос, сколько люди готовы заплатить за нечто. Правда заключается в том, что единственный способ определить, сколько люди готовы платить за нечто — это выставить нечто на продажу и посмотреть, сколько реально человек его купит.
Затем вы можете поиграться с суммами, чтобы измерить чувствительность рынка к цене и попробовать установить кривую спроса. Но пока у вас нет 1,000,000 клиентов и пока вы не уверены абсолютно, что клиент A никогда не узнает, что вы предложили клиенту B более выгодную цену — вы не получите удовлетворительные результаты.
Есть такое стойкое убеждение, что эксперименты, ставящиеся на большом количестве людей должны работать примерно так, как эксперименты на химии в школе. Но каждый, кто экспериментировал на людях, знает, что вы получите широко различающиеся результаты, которые просто не получается повторить. И едиственный способ быть уверенным в своих результатах — это тщательно избегать повторения одного и того же эксперимента дважды.
И, в действительности, вы не можете быть уверены даже в том, что кривая спроса стремится вниз.
Единственная причина, по которой мы исходили из этого тезиса, заключается в том, что мы считали, что «если Фредди хочет купить пару кедов за $130, то он однозначно будет готов их купить за $20.» Верно? Черта-с-два! Нет и нет, если Фредди - американский тинейджер. Американский тинейджер скорее сдохнет, чем появится на публике в кедах за $20. С ума сойти! Кеды? В школе? За двадцать баксов?!
И я не шучу: цена — это сообщение. Билет в кинотеатр в моем городе, стоит, я думаю, $11. Был, однако, кинотеатр, который брал по $3 за вход. Кто-то туда ходил? НЕ-А. Ведь очевидно, что это была помойка для плохих фильмов. Кто-то сейчас находится на дне реки в бетонных «кедах за $20», потому что он осмелился сказать публике, какие фильмы являются сейчас отстойными.
Понимаете, люди склоняются к мысли, что вы получаете то, за что платите.
Последний раз, когда мне нужно было много дискового пространства, я вложил свои деньги в замечательные дешевые диски, оформленные господином Порше лично, что в итоге получалось около $1 за гигабайт. В течении шести месяцев все четыре диска умерли. На прошлой неделе я заменил их на SCSI-диски Seagate Cheetah, что стоят в среднем $4 за гигабайт, потому что я пользовался этими дисками с момента основания своей компании четыре года назад — и без малейших проблем. «Вы получаете то, что за что платите».
Просто существует слишком много примеров, когда вы действительно получаете то, за что платите, и средний покупатель решит, что тот продукт лучше, что дороже стоит. Покупаете кофеварку? Хотите действительно хорошую кофеварку? У вас есть два выбора. Первый — сходите в библиотеку, найдите нужный номер журнала для покупателей с обзорами, или сходите в Williams-Sonoma и купите там самую дорогую кофеварку.
Когда вы устанавливаете цену, вы посылаете сообщение. Если цена ПО вашего конкурента попадает в промежуток от $100 до $500, и вы решаете, блин, все же мой софт находится в процессе разработки, и я буду выставлять счета на $300, так вот, какое, думаете, сообщение вы посылаете своим клиентам? Вы говорите им, что ваш софт это «нуу, понимаете...». У меня есть лучшая идея: требуйте $1350. Теперь ваши клиенты будут думать — ну, чувак, это должна быть нефиговая софта, раз за нее хотят такие бабки.
И они не купят ее, потому что лимит на корпоративной карточке AMEX — это $500.
Мистика.
Чем больше вы учите про ценообразование, тем меньше вы знаете.
Я потратил на эте тему уже больше 5000 слов, и у меня все еще нет ощущения, что мы к чему-то пришли, мы с вами.
Иногда мне кажется, что было бы проще работать таксистом, где цены закреплены законодательно. Или продавать сахар. Просто сахар. Да. Это было бы сладенько.
Воспользуйтесь моим советом, данным 20 страниц назад: требуйте $0.05 за вашу программу. Или же, если она предназначена для багтрекинга, то тогда ее цена — это $30,000,000. Спасибо за внимание, и примите мои извинения, что теперь вы знаете о ценах еще меньше, чем знали до прочтения этой статьи.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Весна в Кэмбридже
Автор: Джоэл Сполски
Переводчик: Семён Хавкин
Редактор: Маргарита Исаева
19 марта 2001
Хоть градусник и показывает чуть больше нуля, а ветер ещё вполне зимний, но сегодня я встал и вышел на улицу и понял: наконец-то пахнет весной. Кажется, я заметил это ещё в пятницу, когда сидел в нашем садике в одной футболке и не озяб.
Весна для меня полна забавных воспоминаний. Я думаю о том, как здорово, что после ужина на улице ещё светло. Я думаю о том, как замечательно жить в старом неубранном доме с настоящими деревянными полами, с разбросанными повсюду книгами, с цветами в саду. Я думаю о двух моих любимых весенних местах, Беркли и Бостоне, городах, где жизнь крутится вокруг учёбы и образования и несдержанного энтузиазма молодёжи и уверенности, что всё возможно. Когда я только поступил в университет, у меня не было ни малейшего представления о том, какой окажется моя дальнейшая жизнь, но по сравнению с неизъяснимо жутким периодом обязательной военной службы, всё на свете было для меня просто утопией. Можно ходить в театр! Можно писать в университетскую газету! Заниматься политикой! Хакерством! Искусством! Преподавать! Я мог бы стать пловцом-спортсменом! Играть на пианино! Всё, всё возможно!
Году в 1993 я наконец-то получил доступ к вебу из дома. 35 долларов в месяц, SLIP от Panix'а. Одним из первых моих очарований были написанные Филипом Гринспаном (Philip Greenspun) Путешествия с Самантой. Разобрать картинки в 16 цветах VGA было почти невозможно; скорость доступа была всего 14.4 килобит в секунду, а экран размером 640 на 480. Но гринспанов стиль личного дневника меня захватывал. Он рассказал, как одиноко ему было три месяца в Лос-Аламосе. Он рассказал, как построить сетевое содружество. Он рассказал про свою печку «Викинг» за пять тыщ.
Для многих из нас Гринспан был вдохновением. Он организовал фирму под названием arsDigita, вроде бы обыкновенную консалтинговую компанию для Интернета, но две вещи делали её уникальной.
У неё был свой голос. На её заглавной странице всегда была радостная заметка об их новом кабинете или о курсе обучения; это не был скучный корпоративно-бюрократический стиль, а просто Филип, говорящий, что если у вас нету денег, то вот возьмите чего есть бесплатного, ну а если деньги есть, то заходите вот сюда, и мы построим вам ваш собственный сайт — только, пожалуйста, возьмите денег побольше, потому что будущее так светло и ясно, нам не обойтись без солнечных очков.
И эта фирма обучала. Веб тогда был делом новым и зажигательным и предлагал неограниченные возможности. Все хотели узнать о нём побольше — и arsDigita готова была вас научить задаром, начиная с , которая стоила на 15 долларов больше, чем это того стоило, потому что была полна совершенно неуместных цветных фотографий, которые там и были, казалось, только для того, чтобы удовлетворить эгоизм авторского увлечения фотографией, но на самом деле они были такие цветные и яркие и оптимистичные, что и читатели книжки (а равно и читатели гринспановского сайта, тоже заполненного фотографиями) не могли не смотреть на будущее Интернета оптимистично и радостно; а к тому была и целая глава про то, как организовать консалтинговую компанию прямо как Филип и сколотить состояние на Интернете — с приложением расценок и бухгалтерских расчётов, как добиться дохода в 250 тысяч у.е. в год, чтобы позволить себе печку «Викинг» ценой в 5 кусков монет и прекрасную квартиру на Гарвардской площади, весной, с набухающими почками и жизнерадостными молоденькими студентками, которые прямо на глазах вырастают из своих лифчиков... Поток сознания, совершенно произвольный, вперемешку с недоделанными кусками кода на Oracle SQL — но, чёрт побери, у него был свой голос!
(Знаю-знаю, любой на фирме arsDigita скажет: "нет, Джоэль! Что нас отличает, так это открытые исходные тексты программ". Или сетевая группа пользователей. Или программа управления контентом. Извините — скучно. А нескучно было, когда у arsDigita был в Интернете свой голос, который можно было воспринимать по-человечески, а людям это и надо, потому что мы человеки.)
Фирма Fog Creek Software получила немалое вдохновние от arsDigita; кодовое название для неё было "PaxDigita", и мы пошли по пути их шутливого лозунга: "У нас нету венчурного капитала, зато есть деньги". arsDigita считала, что для успеха этого достаточно.
Две вещи, мне казалось, arsDigita делала не так. Во-первых, они не понимали, что консалтинг плохо масштабируется; для настоящего эффекта нужно лицензировать продукт. Консультант, работающий на проекте, получает прибыль десять–двадцать процентов. Если же вы лицензируете программу, каждая новая продажа даёт вам 100 процентов прибыли. Поэтому биржевая цена программистских компаний раз в 25 больше, чем консалтинговых. Консалтинг — штука важная, он не даёт нам потерять связь с нашими покупателями, он финансово обеспечивает разработку софта, но цель наша — быть программистской фирмой. (Похоже, arsDigita это осознала. Их руководитель Ален Шахин (Allen Shaheen) пишет: "мы также предполагаем разработку и маркетинг других программных продуктов, под другими лицензионными условиями. Это идёт в дополнение к нашим усилиям по разработке ACS как продукта с открытыми исходными текстами. Мы рассматриваем этот подход, поскольку он позволит нам ускорить разработку новой, улучшенной функциональности". На нормальном языке это значит: "Теперь за новые функции вы будете платить".)
Что ещё мне не нравилось в arsDigita — это почти религиозное отвращение к Microsoft'у. [Сам-то Джоэль прежде работал в Microsoft'е. —Прим.пер.] Они были глубоко убеждены, что избегая майкрософтовских продуктов, "избегают риск". По правде же, они просто ничего не знали об этих продуктах. Это их религиозное рвение мне казалось фанатизмом. По словам Лазаруса Лонга (Lazarus Long): Если вы говорите: "с Юниксом мы знакомы лучше, так что с ним у нас будет лучше получаться", то вы поступаете как учёный. Если же вы говорите: "мы не используем майкрософтовское дерьмо, это полный отстой", то вы просто фанатик, а это мешает делу. (Гринспан это осознал; почти вся его желчь в отношении Microsoft'а, похоже, растворилась, и теперь он наконец-то признаёт: Я не готов затевать религиозную войну ради конкретной базы данных или веб сервера. Приятно смотреть, как умные люди растут.)
Но одну вещь arsDigita делала очень, очень правильно — у нее был свой голос. И с Fog Creek'ом меня прежде всего заботит сохранение собственного голоса. Если мы сможем этого добиться, я буду большим должником Филипа Гринспана.
У arsDigita весна закончилась. Во время доткомовского бума им не удалось нанять инженеров без того, чтобы наобещать им золотые горы IPO. Они набрали 38 миллионов долларов венчурного капитала. Они выросли с 5 до 250 человек.
...А затем пору перевозбуждённого рынка сменила рецессия.
Начальники быстренько ввели скучнейших руководителей старой школы, которые настояли на бессмысленном бюрократическом сайте, полном ерунды вроде: "Полностью интегрированный по единой модели данных с целью единообразного обслуживания деловых процессов, ACS позволяет предприятиям и организациям создавать веб сервисы, максимизирующие значение для конечного пользователя."
Филип .
Голос затих.
arsDigita всегда будет напоминать мне об этих нелишних картинках: хорошеньких девушках на роликах, киосках по продаже моллюсков, лодочках на речке Чарльз, закатах в Нью-Мексико, цветах, весне; и если вы дело сделаете, народ к вам придёт, и если у вас есть свой голос, им будет не всё равно. Когда я сегодня иду на их сайт и вижу, что они "максимизируют значение для конечного пользователя", я вспоминаю того радостного студента-мальчишку, играющего в футбол, журнализм, театр, политику, который в любое мгновение был готов изменить весь мир. Теперь он женат, у него два с половиной ребёнка, он ходит на работу в страховую компанию и весь день носит там серый костюм.
Печальная это штука, взрослость.
Но в воздухе пахнет весной, и значит — не всё потеряно!
Комментарии переводчика.
SLIP — один из протоколов для связи компьютера с Интернетом. Теперь уже используется не так часто, особенно по сравнению с PPP.
Panix — один из популярных ISP в ранние времена развития веба в США.
Fog Creek Software можно перевести как Программы Туманного Ручья. Но это просто название фирмы Джоэля.
ArsDigita можно перевести как Цифровое Искусство. Но это просто название фирмы Филипа.
PaxDigita можно перевести как Цифровой Мир. Но можно и не переводить.
Венчурный капитал — . Скукотища.
IPO, т.е. Initial Public Offering, начало циркуляции акций компании на бирже. Обычно сопровождается скачком стоимости этих акций по отношению к внутренней цене, что означает большую выгоду, хотя и на бумаге, для владельцев акций. Хорошим тоном считается привлечение работников фирмы к участию в IPO, что является для них дополнительным (а подчас и основным) стимулом заинтересованности в успехе фирмы.
У.е. — условная единица, в точности равная одному доллару.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Выбор даты выпуска
Автор: Джоэл Сполски
Переводчик: Андрей Шкуропий
Вторник, 9 апреля 2002
Одна из наиболее весомых причин составить детальный в том, что он дает вам обоснование для фильтрации функциональных возможностей программы. Если невозможно успеть к положенному сроку выпуска и реализовать функцию MP3-чата, которую предложил программист Боб, то можно легко отсечь эту функцию, не особенно огорчая при этом Боба.
Итак, мое основное правило для циклов выпуска программных продуктов:
Установить дату выпуска, которая может быть совершенно произвольной
Составить список функциональных возможностей и отсортировать их по приоритету
Отсекать низкоприоритетные возможности каждый раз, когда вы замечаете, что сроки выпуска сползают с выбранной даты
Кстати, если вы этого не сделаете, то можете ненароком позабыть о том, чтобы реализовывать возможности в порядке приоритета. Если вы будете беспечны, ваши программисты будут реализовывать функциональные возможности в порядке их прикольности, и вы не сможете выпустить программу вовремя или усечь функционал, потому что все программисты были заняты созданием функции Просчета Караоке прежде чем хотя бы заставить работать меню, и вот теперь, шесть месяцев спустя после того дня, в который вы хотели сделать релиз, у вас есть красивенное вместо функциональности.
Итак, очевиден следующий вопрос: как вы выбираете дату выпуска?
Вполне вероятно, что у вас есть внешние ограничения. Фондовая биржа (ваш заказчик) переходит с обычных дробей на десятичные дроби в такой-то день, и если вы не успеете поставить им работающую программу, ваша фирма будет выброшена из бизнеса, а вас вывезут в тихую пристань и пристрелят в голову. Или может быть скоро выходит новая версия ядра Linux, опять с совершенно новой системой фильтрации пакетов; его устанавливают все ваши клиенты; и ваше существующее приложение не хочет работать на нем. Ясно, что для этих людей легко определить дату выпуска. Вы можете прекратить чтение этой статьи прямо сейчас. Идите, приготовьте лучше вкусный обед для вашей возлюбленной.
Пока!
Но как выбрать дату выпуска всем остальным?
Есть три подхода к решению этой задачи.
Частые небольшие релизы. Это подход Экстремального Программирования, и он наиболее подходит для проектов с небольшой командой разработчиков и с малым количеством клиентов, таких как домашняя IT-разработка.
Каждые 12–18 месяцев. Это обычно программные продукты «в упаковке», такие как настольные приложения и т.д., у которых большие команды разработчиков и тысячи или миллионы пользователей.
Каждые 3–5 лет. Это типично для гигантских программных систем и платформ, которые являются целыми мирами сами по себе. Операционные системы, .Net, Oracle, и по некоторым причинам Mozilla попадают в эту категорию. Они часто имеют тысячи разработчиков (VS.Net имеет 50 человек только в команде для создания инсталлятора) и весьма сложно взаимодействуют с другими программными продуктами, которые не должны «упасть».
Вот несколько вещей, о которых вы должны помнить во время принятия решения, как часто делать релизы ПО.
Короткие сроки выпуска находят быстрый отклик у пользователей. Иногда наилучший способ работы с клиентом – показать ему код, позволить испытать его и сразу включить их пожелания в следующую сборку программы, которую вы даете им заново каждый день. Вы не захотите тратить целый год на разработку сложной системы с огромным количеством функций, которые никто не использует, потому что вы будете очень заняты созданием вещей, которые пользователи просят сделать прямо сейчас. Если у вас малое количество клиентов, используйте частые выпуски с небольшими усовершенствованиями. Каждый минимальный фрагмент изменений в очередном выпуске программы должен делать что-то полезное.
Несколько лет назад меня назначили на разработку системы управления веб-содержимым для MTV. Требования были такие: надо было создать веб-систему с поддержкой базы данных, с шаблонами и подсистемой полного документооборота, которая позволяла бы бесплатным внештатным корреспондентам MTV из колледжей по всей стране вводить информацию о клубах, магазинах звукозаписи, радиостанциях и концертах. Я спросил: «А как вы сейчас строите свой сайт?»
«А, мы просто делаем это все вручную с помощью программы BBEdit», сказали они мне. «Конечно, вручную обрабатываются тысячи страниц, но BBEdit имеет действительно классную функцию Поиска-с-Заменой…»
Я оценил длительность разработки всей системы в шесть месяцев. «Но позвольте мне предложить кое-что другое. Давайте сначала запустим механизм шаблонов. Я могу сделать его вам за 3 месяца, и он сразу спасет вас от тонн ручной работы. Как только он будет готов, я начну работать над подсистемой документооборота; а пока я не закончу, вы можете продолжать документооборот через электронную почту.»
Они согласились. Это звучало как хорошая идея. И вы знаете что? Как только я выдал на-гора механизм шаблонов, они поняли, что в действительности не так уж нуждаются в подсистеме документооборота. И оказалось, что механизм шаблонов оказался полезным для многих других веб-сайтов, которым тоже не был нужен документооборот. Так что мы документооборот так и не построили, сэкономив три месяца, которые я использовал для совершенствования механизма шаблонов, оказавшегося более полезным.
Определенные типы пользователей не желают быть «подопытными кроликами» в такой форме. Обычно люди, которые покупают программные продукты «не для полки» (off-the-shelf software), не хотят быть участниками Великого Эксперимента по Разработке; они хотят что-нибудь, предугадывающее их потребности. Для пользователя единственное, что может быть лучше быстрого отзыва разработчиков на запрос новых функциональных возможностей, – это когда они получают их немедленно, потому что эти функциональные возможности уже предусмотрены в программном продукте, так как он разрабатывался внимательно и прошел усиленное юзабилити- и бета-тестирование прежде чем был выпущен в свет. Если у вас большое количество платежеспособных пользователей (или вы хотите, чтобы их стало больше), предпочитайте менее частые выпуски.
Если вы выпустите худосочную коммерческую программу просто для того, чтобы выставить что-нибудь на обозрение и «начать слушать пользователей», то услышите, что пользователь говорит: «эта программа мало что может», и вы подумаете, что это нормально. Эй, это всего лишь версия 1.0. Но затем, если вы выпустите версию 2.0 через четыре месяца, то все начнут думать: «Ах, это та ничтожная программа? Я что, должен продолжать оценивать ее каждые четыре месяца, просто чтобы убедиться, что она уже стала лучше?» И, по сути, пять лет кряду люди все еще будут помнить свое первое впечатление от версии 1.0, и их практически невозможно будет переубедить. Подумайте о том, что случилось с несчастной Маримбой (Примеч. переводчика: Marimba – африканский ударный инструмент, а также название программного продукта компании «BMC Software», который призван уменьшить стоимость информационных технологий компании путем автоматизации критических функций управления клиентами корпоративных сетей). Они запустили свою компанию с бесконечным венчурным капиталом в дни сверхэнергичной рекламной кампании Java, переманив ключевых разработчиков из команды Java фирмы Sun. Их генеральный директор, Ким Полиз (Kim Polese), была непревзойденным пиарщиком; когда она продавала Java, Дэнни Хиллис (Danny Hillis) писал ей речи о том, что Java – это следующий этап эволюции человечества; Джордж Гилдер (George Gilder) писал все эти захватывающие дух статьи о том, как Java полностью перевернет саму природу человеческой цивилизации. В общем, монотеизм был просто микробом, по сравнению с тем, как мы верили в Java. Ким Полиз в этом действительно преуспела. Так что когда была выпущена Маримба Кастаньет (Marimba Castanet), она была, наверное, самым раскрученным продуктом в истории, но разработчики работали над ней всего… четыре месяца. Мы все скачали ее и увидели что – тадам! – это было окно со списком, которое скачивало программы. (А чего вы ожидали от четырех месяцев разработки?). Большой облом. Разочарование было таким жирным, что вы могли его намазывать на хлеб вместо масла. И сейчас, через шесть лет, спроси у кого угодно, что такое Кастаньет, и вам скажут, что это окно со списком, которое скачивает программы. Едва ли кто-нибудь побеспокоился переоценить ее, и код Маримбы должен был переписываться шесть лет; я уверен, что сейчас это самая крутая программа, но, если по-честному, у кого было время это узнать? Скажу вам маленький секрет: наша стратегия для – избежать массивного пиара до выпуска версии 2.0. Это будет та версия, о которой все на Земле должны получить первое впечатление. А пока что мы будем вести тихий , и любой из тех людей, кто на нее наткнется, обнаружит, что это весьма нехилая программа, которая решает многие их проблемы, но не потребуется ничего переписывать (Примеч. переводчика: Arnold Toynbee – автор нескольких книг по истории цивилизации).
Ну ладно, если 15 месяцев – это хорошо, то может быть 24 месяца – еще лучше? Может быть. Некоторые компании могут тянуть сколько угодно, если они главные лидеры в этой категории. Разработчикам PhotoShop это, кажется, сойдет с рук. Но как только приложение начнет выглядеть устаревшим, люди перестанут покупать его, потому что ожидают выпуска новой версии со дня на день. Это может вызвать серьезную потерю дохода для софтверного бизнеса. И, конечно же, у вас могут быть конкуренты, которые наступают вам на пятки.
Для больших программных платформ – операционных систем, компиляторов, веб-браузеров, СУБД – самая трудная часть процесса разработки – обеспечение совместимости с тысячами или миллионами существующих программных или аппаратных продуктов. Когда выходит новая версия Windows, вы очень редко слышите о проблемах обратной совместимости. Единственный способ, которым они могут этого достичь – проведение немеряного количества тестов, по сравнению с которыми создание Панамского канала – просто самоделка на один уикенд.
Почти все время типичного трехлетнего цикла между выпусками новых «старших» версий Windows тратится на занудные фазы интеграции и тестирования, а не на создание новых функций. Выпускать новые версии чаще, чем они это делают, просто нереально. И если они будут делать их чаще, это сведет людей с ума. Третьи стороны в разработке программного и аппаратного обеспечения просто поднимут бунт, если вынуждены будут снова тестировать множество маленьких релизов операционной системы. Для систем с миллионами пользователей и миллионами точек интеграции, предпочитайте редкие выпуски. Вы можете делать это также, как Apache: один релиз в начале Разбухания Интернета (Примеч. переводчика: Internet Bubble – печально известный кризис Интернет-компаний 1997–2000 гг.) и один релиз в конце. Прекрасно.
Но не переоцените свои возможности по доведению проекта до конца, основываясь только на высококачественных ежедневных сборках. Даже если ошибки у вас постоянно на нуле, когда ваша программа выйдет в Дикую Природу, вы никогда сами не найдете все ошибки совместимости, и глюки под Windows 95, и ошибки включенных больших шрифтов, пока не сделаете несколько бета-версий, и нет никакого реального способа сделать цикл бета-тестирования короче, чем 8 недель.
И последнее. Если ваша программа поставляется как веб-сервис, вроде e-bay или PayPal, теоретически ничто не останавливает вас от частых небольших выпусков, но это может быть не самым лучшим вариантом. Помните : приложение удобно для использования, если оно ведет себя так, как ожидает пользователь. Если вы каждую неделю меняете что-нибудь, это не будет предсказуемо, и, следовательно, будет не так удобно. (И не думайте, что вы сможете обойти эту проблему с помощью одного из этих надоедливых экранов с текстом, который говорит «Внимание! Интерфейс был изменен!» .) С позиции юзабилити лучшим подходом будет скорее выпуск небольших частых релизов, которые будут включать в себя целый пакет изменений, и вы приложите усилия, чтобы изменить внешний вид всего сайта. А когда он будет выглядеть по-новому, то пользователи интуитивно поймут, что вещи сильно изменились и будут более осторожны.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
Закон Дырявых Абстракций
Автор: Джоэл Сполски
Переводчик: Семён Хавкин
Редактор: Маргарита Исаева
23 марта 2000
Есть в Интернете инженерное волшебство, на работу которого мы с вами полагаемся каждый день. Оно заключено в сетевом протоколе TCP, одном из основных кирпичей, из которых выстроен Интернет.
TCP — способ пересылки данных, который считается надёжным. Это значит: если вы с его помощью отсылаете сообшение по сети, оно обязательно прибудет на место в неискажённом виде.
Мы все пользуемся TCP для повседневных нужд: загрузить страничку с веба, послать электронную почту. Надёжность TCP позволяет всякому рассылать по миру наивысшего качества. О счастье, о радость!
Посмотрим теперь на другой, ненадёжный, метод пересылки данных под названием IP. Тут уже никто не обещает, что посылка доедет до места назначения, и что по дороге с ней ничего не случится. Отправляя через IP кучу сообщений, не удивляйтесь, если половина из них потеряется, а из остальных часть окажется совсем не тем, что посылалось: может, они будут содержать фотографии прелестных котят, но скорее всего — просто нечитаемый мусор, вроде столь любимого нами всеми тайваньского спама.
Волшебство же состоит в том, что TCP основан на IP. Иными словами, TCP обязуется работать надёжно, используя лишь ненадёжные детали.
Для иллюстрации волшебства, рассмотрим аналогичный, хотя и не вполне обычный, сценарий из реальной жизни.
Предположим, некая дама отправляла подводами из Петербурга в Москву диван, чемодан, саквояж и т.д. Часть подвод сломалась и до Москвы не доехала. Часть подвод опрокинулась по пути, разбив картину, картонку и зеркала. Подводы добирались до Москвы не в том порядке, в каком выезжали из Петербурга, поскольку некоторых задержали страшные лесные разбойники, и вообще возницы выбирали разные маршруты. А теперь представим, что даме предлагается новая услуга: Красная Стрела, которая гарантирует, что багаж (а) прибудет на место (б) в целости и сохранности (в) и в нужном порядке.
Но волшебным образом Красная Стрела не использует, как вы подумали, железной дороги, а нанимает тех самых возниц с подводами. Красная Стрела организует работу возниц следующим образом. Состояние багажа каждой подводы тщательно проверяется. В случае повреждения диван, чемодан и проч. заменяются со склада точно такими же. Подводы выстраиваются в правильном порядке. Если страшные лесные разбойники сумели захватить Бологое и перерезать дорогу, то Красная Стрела перенаправляет подводы другим путём, и дама ничего не подозревает. Ей просто кажется, что багаж прибывает немного медленнее, чем обычно; а об ужасных событиях в Бологом даме знать необязательно.
Примерно так TCP и работает. По-учёному это называется абстракция: упрощённое описание процесса, механизм которого остаётся скрытым. На самом деле, значительная часть программирования заключается в построении абстракций. Что такое, допустим, строковая библиотека? Это способ сделать вид, что компьютеры умеют легко работать со строками, яко бы с числами. Что такое файловая система? Это способ сделать вид, что жёсткий диск состоит не из быстро вращающихся намагниченных тарелок, которые умеют сохранять биты в определённых местах, а якобы представляет из себя иерархическую систему папок внутри папок, внутри которых отдельные файлы содержат, в свою очередь, байтовые цепочки.
Вернёмся к TCP. Я тут для простоты слегка загнул, и у кого-то, может быть, от этого уже пар из ушей пошёл. Короче, я сказал, будто TCP гарантирует, что сообщение прибудет на место. На самом деле, это не так. Если ваш любимый хомячок перегрызёт сетевой кабель, так что никакие пакеты IP не дойдут до компьютера, то TCP ничего не сможет поделать, и сообщение не придёт. Если же вы поругались с сетевым администратором, который в отместку включил ваш компьютер в перегруженный , то много пакетов IP потеряется, и хотя TCP будет работать, но так медленно, что за время пути собачка, сами понимаете, того.
Вот это я и называю дырявой абстракцией. TCP пытается абстрагироваться от ненадёжной сети полностью, но иногда эта сеть все-таки просвечивает сквозь дыры в абстракции, так что абстракция не всегда защищает от необходимости иметь дело с глубокими подробностями.
Это всего лишь один пример того, что я назвал Законом Дырявых Абстракций:
Простой пример: итерация по большому двумерному массиву может идти с совершенно разной скоростью, смотря как он обходится: горизонтально или вертикально. Как и в , которое легче раскалывать вдоль волокна, а не поперёк, одно направление может вызывать значительно больше , чем другое, а отказы обслуживаются долго. Даже программистам на ассемблере приходится делать вид, что у компьютера большая плоская память, но в системе виртуальной памяти это всего лишь абстракция, в которой при отказе памяти образуется дырка, так что отдельные обращения к памяти могут занимать значительно больше наносекунд, чем обычно.
Язык SQL был создан, чтобы абстрагироваться от процедурных шагов, нужных для запросов к базе данных. Вместо этого он позволяет описать, что именно запрашивается, и пусть база данных сама догадается, какие процедурные шаги для этого нужны. Но в иных случаях некоторые запросы SQL в тысячи раз медленнее, чем другие, логически им эквивалентные. Известный пример: некоторые сервера SQL значительно быстрее отрабатывают запрос where a=b and b=c and a=c , чем where a=b and b=c , хотя результат, конечно, тот же самый. Программисту на SQL вроде бы и не следует заботиться о процедуре, только о спецификациях. Но иногда абстракция протекает, что приводит к страшным потерям в производительности, так что приходится лезть во внутренности планировщика запросов и смотреть, что там не так, и как заставить его работать эффективнее.
Хотя сетевые библиотеки, вроде NFS и SMB, позволяют работать с файлами на других машинах как на своей, иногда связь становится очень медленной или просто падает, и дальний файл перестаёт прикидываться местным; а ведь программисту надо писать код так, чтобы и в этой ситуации всё работало. Значит, в абстракции "всё равно, где лежит этот файл" есть .
Вот пример для системных администраторов Юникса. Если домашние директории лежат на дисках, подмонтированных по NFS (одна абстракция), а пользователи создают файлы .forward для автоматической пересылки почты в другое место (вторая абстракция), и сервер NFS падает, а почта всё прибывает, то никуда она не перешлётся, поскольку файл .forward будет недоступен. Так сквозь дырку в абстракции письма могут просыпаться на пол.
Строковые классы должны представлять строчки в виде . Они абстрагируются от того, что , и дают возможность работать с ними легко, ну прям как с числами. Почти все строковые классы C++ перегружают оператор +, и для конкатенации строчек можно писать s+"bar". Но как ни старайся, никакой на свете строковый класс C++ не даст вам написать "foo"+"bar", поскольку строковые литералы в C++ всегда имеют тип char*, а не string. Абстракция прохудилась так, что языком C++ её не заткнёшь. (Интересно, что историю развития C++ можно описать как историю затыкания дырок в абстракции строк. Уж не знаю, отчего бы не добавить к языку элементарный класс строчек.)
И ещё: несмотря на дворники, мощные фары, крышу и обогреватель, которые защищают (абстрагируют) от непогоды, под дождём быстро ехать нельзя; приходится иметь дело с водяной подушкой, а иногда ливень такой, что на дороге ничего не видно, и надо остановиться; так что и погоду, из-за закона дырявых абстракций, полностью не абстрагируешь.
Закон дырявых абстракций означает, к сожалению, что абстракции не так сильно упрощают нашу жизнь, как хотелось бы. Если я обучаю программистов C++, было бы здорово, если бы мне не нужно было рассказывать им про char* и арифметику указателей, а можно было сразу перейти к строкам из стандартной библиотеки темплейтов. Но в один прекрасный день они напишут "foo"+"bar", и возникнут странные проблемы, а мне придётся всё равно объяснить им, что такое char*. Или они попытаются вызвать функцию Windows с параметром типа LPTSTR и не смогут, пока не выучат char* и указатели и Юникод и wchar_t и хедерные файлы TCHAR — все то, что просвечивает через дырки в абстракциях.
Когда я обучаю кого-то программированию COM, было бы здорово ограничиться визардом Студии и автоматической генерацией кода, но если что-то выйдет не так, у них не будет ни малейшего понятия, что случилось и как это исправить. Значит, надо рассказывать им про IUknown и CLSID и ProgIDS и... о боги!
При обучении программистов ASP.NET было бы здорово сказать: мол, дважды кликните мышом на штучку, а затем пишите код, который должен отрабатываться на сервере, когда пользователь кликнет на эту штучку. И правда, ASP.NET абстрагирует разницу между написанием кода HTML для отработки нажатия на гиперссылку (<a>) и кода для отработки нажатия на рисованную клавишу. Проблема: разработчикам ASP.NET пришлось скрыть тот факт, что в HTML нету способа отсылать форму из гиперлинка. Они обходят это, генерируя несколько строчек на JavaScript и добавляя к гиперлинку функцию onclick. Но эта абстракция дырява. Если пользователь отключит JavaScript, то приложение на ASP.NET не будет правильно работать; и если программист не знает, что именно абстрагировалось ASP.NET'ом, он не поймёт, в чём там дело. Из-за закона дырявых абстракций вот что получается: придумает кто-нибудь чудесный новый генератор кода, с которым у программиста работа наконец-то станет эффективной, а ему и говорят: "Сперва научись делать это руками, а потом уж пользуйся генератором, чтобы сэкономить время". Генераторы кода, абстрагирующие разработку кусков кода, так же дырявы, как и все прочие абстракции. А единственный компетентный способ залатать эти дыры - выучить, как работают абстракции, и какие подробности они скрывают. Итак, абстракции экономят наше рабочее время, но не экономят учебное время.
Отсюда парадоксальное следствие: в то время как инструментарий программиста забирается на всё более высокие уровни сложности со всё более развитыми абстракциями, подготовить высококвалифицированного программиста становится всё труднее.
Во время мой первой стажировки в Microsoft я писал строковые библиотеки для Макинтоша. Типичное задание: написать версию функции strcat, которая возвращает указатель на конец новой строки. Несколько строчек кода на C. Всё, что я делал, пришло прямо со страниц , одной тоненькой книжки про язык C.
Сегодня же для работы над CityDesk'ом мне нужно знать Вижуал Бэйсик, COM, ATL, C++, InnoSetup, внутренности Эксплорера, регулярные выражения (RegExp), DOM, HTML, CSS и XML. Всё это инструменты более высокого уровня по сравнению со старым K&Р, а всё ж таки мне и его надо знать, не то беда.
Десять лет назад можно было мечтать, что на сегодняшний день новые компьютерные концепции облегчат труд программиста. И правда: созданные за эти годы абстракции позволяют работать с проектами на порядки более сложными, чем десять или пятнадцать лет назад, типа программирования GUI и сетевого программирования. Но хотя замечательные инструменты, вроде современных объектных языков визуальных форм, позволяют сделать много и очень быстро, вдруг в один злосчастный день приходится искать течь в абстракции, и на это уходит пара недель. А когда вам нужно найти себе программиста в основном на Вижуал Бэйсике, совершенно недостаточно нанять программиста только на Вижуал Бэйсике, потому что каждый раз, когда абстракции Бэйсика потекут, он не сможет сделать ни шага.
Закон дырявых абстракций крепко держит нас за штаны.
Комментарии переводчика:
*) "Остапу Бендеру из Восточной Африки". Или из Западной; жулик - он везде жулик. Но ссылка на Африку неслучайна. Во-первых, подчёркивается проникновение высоких технологий в самые отдалённые и технически отсталые уголки населённого мира. А во-вторых, как раз в период написания статьи из этой самой Африки по всему миру прокатилась волна вопиющего .
*) Спам. Казалось бы, spam — простая тушёнка. Но благодаря одному из номеров популярного среди древних программистов сатирического коллектива «Монти Питон» (Monty Python), так стали называть всякое ненужное барахло, рассылаемое по электронной почте вовсе того не желающим абонентам.
*) Хаб — сетевой узел, в котором встречаются провода, по которым передаётся информация.
*) В случае с поленом речь идёт не о Буратино, а о волокне древесины; по-английски grain of the wood. Подобный термин (шуточный, но точный) в русском языке, насколько мне известно, не устоялся. Речь идёт о том, что перебор элементов массива в том порядке, в котором они физически лежат в памяти, бывает значительно эффективнее (т.е. быстрее). Похожим образом, колоть дрова проще, когда лезвие топора ложится вдоль волокон, а не поперёк.
*) Отказ памяти у компьютеров происходит, когда искомого не находится в ближней памяти, и приходится лезть за ним в память более далёкую. Это может происходить на различных уровнях иерархии: если нужной информации нет в кэше, надо обращаться в оперативную память, при отказе оперативной памяти — во вторичную память (например, жёсткий диск), и так далее. Такой процесс проваливания на следующие уровни стоило бы по-русски назвать провалами памяти, но увы.
*) Гражданами первого класса называются элементы языка программирования, имеющие значения, с которыми можно обращаться как с обычными переменными, а именно: присваивать, передавать в качестве параметров, возвращать из функций-подпрограмм.
*) К&Р — так программисты нежно называют классическую книжку Кернигана и Ричи, «Язык программирования C». Джоель использует этот термин и в более широком смысле - как стиль программирования.
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
