lkurts' shared items in Google Reader

NASA's Hubble Captures Strange Spaceship-Like Object Going 11,000MPH

2010-02-02T11:00:00Z

NASA's Hubble Space Telescope recently captured a strange, spaceship-like object traveling at 11,000mph. Unlike comets, this object has an "X-shaped debris pattern [and] its 460-foot-wide nucleus is outside the dust halo and separated from the trail." Continue reading for a close-up.

This behavior is something which has never been seen before in a comet or any other solar-system-swooshing object.

[via Gizmodo]

"Компьютерра" не пережила кризис

2009-12-08T13:41:00Z

Сергей Вильянов, главный редактор Computerra.ru, на форуме Helpix.ru объявил о выходе последнего номера бумажной "Компьютерры".

Номер выйдет 15 декабря, в нем будут собраны "прощальные статьи всех заметных людей, когда-либо там работавших". В дальнейшем журнал выходить не будет.

По мере развития Интернета компьютерные и околокомпьютерные журналы чувствовали себя все хуже: журнал "Инфобизнес", принадлежащий ИД "Компьютерра" был возрожден весной 2009-го только в онлайновом виде. Тем не менее, причины закрытия были не финансовые, Дмитрий Мендрелюк, гендиректор ИД "Компьютерра", озвучил их следующим образом:

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

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

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

Новость подсказана читателем Roem.ru. Спасибо

!жиды Дайте рекомендацию по Помоги.орг (+)
!Кэп Дайте рекомендацию по Помоги.орг (+)
Phil_e39 Что за проблемы с каналом у РБК?
chislovod Дайте рекомендацию по Помоги.орг (+)
Ashmanov Ex.: Mail.ru сменит «Яндекс» на Google

Announcing the Chromium OS Open Source Project

2009-11-20T01:49:00Z

Today we released Chromium OS, the open source project behind Google Chrome OS. Google Chrome OS is an operating system that is intended for people who spend most of their time on the web. It aims to provide a computing experience that is fast, simple and secure. The Chromium OS project as you'll see it today is comprised of the code that has been developed thus far, our early experiments with the user interface, and detailed design docs for many parts that are under active development.

To learn more about what Google Chrome OS is, watch this short video:

To get a feel for the Google Chrome OS user experience, you can watch the demo from this morning's announcement event.

Posted by Kan Liu, Product Manager

Язык программирования Go

2009-11-11T14:08:00Z

Сегодня Google представил язык программирования собственной разработки под названием Go. Я почитала о нем наискосок, там есть сборка мусора, высказываются интересные мысли по поводу многопоточности. Пока ничего революционного не обнаружила.

Название для языка выбрано неудачное, поиском его искать плохо.

Официальный сайт языка Go, там есть FAQ.

Новость пользуется популярностью, вот уже многопоточный рейтрейсер написали... A Multi-threaded Go Raytracer

Updated 20.11.2009
Ссылки по теме:
Краткий пересказ Effective Go на русском языке

Microsoft’s Bing—Introducing One of Wolfram|Alpha’s First Commercial API Customers

2009-11-11T18:05:53Z

Having announced the Wolfram|Alpha API just over three weeks ago, I am pleased to share in announcing Microsoft’s Bing decision engine as one of our first API customers.

Starting today, Wolfram|Alpha’s knowledge, computed from expertly curated data, will enrich Bing’s results in select areas across nutrition, health, and advanced mathematics. Wolfram|Alpha provides immediate, unbiased, and individualized information, making it distinctly different from what has traditionally been found through web search. By using Wolfram|Alpha, Bing recognizes the complementary benefits of bringing computational knowledge to the forefront of the search experience.

By using our API, Bing will be able to seamlessly access the tens of thousands of algorithms and trillions of pieces of data from Wolfram|Alpha, and directly incorporate the computations in its search results.

Microsoft’s initiative and interest in Wolfram|Alpha began earlier this year. In fact, there is an interesting story that circulates within our walls around some of our early discussions with Microsoft.

Highlighting examples of Wolfram|Alpha to the most senior executives at Microsoft, Stephen Wolfram entered the query “2^2^2^2^2”. Upon seeing the result, Bill Gates interrupted to say, “What, is that right?”

A profound silence fell over the entire room.

Stephen replied, “We do mathematics!”

Amused, Stephen, Bill, and the other executives dissected the calculation and determined that the result was, indeed, correct. Microsoft continues to pepper us with questions to this day, reflecting its continued enthusiasm in Wolfram|Alpha.

We applaud Microsoft’s vision and foresight in augmenting their search with Wolfram|Alpha, and we look forward to a fulfilling and productive partnership.

Figuring out what your company is all about

2009-11-01T21:51:31Z

What is your company about?

Recently I got inspired by Kathy Sierra, whose blog Creating Passionate Users and Head First series of books revolutionized developer education. She kept saying the same thing again and again: help your users be awesome.

Kathy taught me that if you can’t explain your mission in the form, “We help $TYPE_OF_PERSON be awesome at $THING,” you are not going to have passionate users. What’s your tagline? Can you fit it into that template?

It took us nine years, but we finally worked out what Fog Creek Software is all about, which I’ll tell you in a moment, but first, some backstory.

In the early days, we were all about making a great place to be a software developer in New York City.

Yep, that was all there was to it. Almost every software job in the city was terrible. You had a choice of which kind of terrible. Want to wear a suit and work long hours under crummy conditions? Take a job at a bank. Want to report to a manic-depressive creative who demands that you stretch HTML in ways that would have you put to death, in certain countries? Take a job at a media company. Want to work 24/7 in a basement with water pipes dripping on your head and get paid in worthless stock options? Take your pick of the revenue-free dotcom startups.

Why New York, then? There are lots of great product companies where software developers are treated very well in Redmond, Washington. But I was sick of trying to live in lesser cities. Sure, the Seattle area is beautiful, and green, and clean, and possesses great coffee, and I understand that there are even a couple of grocery stores open late now. But I’m staying in New York, because it’s the greatest city in the world.

I gave up the search, and decided to start a company with my buddy Michael Pryor. Making a nice place to work was our primary objective. We had private offices, flew first class, worked 40 hour weeks, and bought people lunch, Aeron chairs, and top of the line computers. We shared our ingenious formula with the world:

The tagline was “building the company where the best software developers want to work.” It was, to say the least, awkward. It didn’t make for a good elevator pitch. It didn’t really have the right format. “Abercrombie and Fitch: building the apparel store where the hottest teenagers will want to work.” Who cares? Not the hot teenagers, I’ll tell you that.

Anyway we accomplished that goal. Cross it off the list. What’s next? We needed a new mission statement.

And it has to be something of the form, “We help $TYPE_OF_PERSON be awesome at $THING.”

Bells went off. Everything we’ve done successfully has one thing in common: It’s all about helping software developers be awesome at making software.

That includes Joel on Software, Stack Overflow, all the books I’ve been writing, the conferences like DevDays and Business of Software, the Jobs Board and Stack Overflow Careers.

It includes our flagship product, FogBugz, which is all about giving developers tools that gently guide them from good to great. It’s the software implementation of the philosophy I’ve been writing about for a decade, lacking only one thing: the feature to replace exceptions with return values, while adding Hungarian prefixes to all variable names. THAT IS A JOKE, PEEPLE. Put DOWN the bazooka.

Helping you make more awesome software is why I write endlessly about what we’re doing at Fog Creek, despite the fact that people accuse me of shilling. I’m not writing to promote our products. You don’t have to buy our products to get the benefit of reading about my experience designing them and building them and selling them. I’m writing to share some of my experiences in case they can help you make better software.

Our focus on helping developers explains why one of our early products, CityDesk, flopped: it had nothing to do with software developers. And it explains why another of our products, Fog Creek Copilot, only found a market in the niche of software developers doing tech support.

So, here you go, the new tagline: “We help the world’s best developers make better software.”

Going through this exercise made it easy to figure out what belongs in future versions of FogBugz and what doesn’t. In particular, we’re adding source control and code review features to FogBugz, using Mercurial, the best open-source distributed version control system. Everything that helps developers make better software belongs in FogBugz: project planning, project management, bug tracking, and customer service.

It took almost ten years, but I think we finally got the mission for the next ten nailed.

Optional Advertainment: If you’ve got a moment, check out this 4½ minute trailer for Make Better Software, a new video training series we’ve been working on for more than a year. It’s the video edition of Joel on Software and fits perfectly with our agenda of helping developers make great software.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

New-wave campaigning for climate change

2009-10-09T18:00:36Z

On Saturday, October 17, president Mohamed Nasheed of the Maldives will conduct his national cabinet meeting … 20 feet beneath the surface of the Indian Ocean. The president and his ministers will carry out the full monty under the sea with wetsuits, compressed-air tanks and even waterproof pens and paperwork to persuade world leaders of the impending danger of global climate change and the necessity of carbon emissions cuts.

Rising sea levels threaten to submerge the Maldives, an archipelago with an average elevation of 2 meters and a population of 396,000, within this century. For more on the risks of rising sea levels, watch James Balog’s talk on extreme ice loss and Lewis Pugh’s talk on swimming the North Pole. And at TEDIndia in Mysore, we’ll hear from Charles Anderson, a marine biologist who studies ocean life in the Maldives.

International release of Kindle 2!

2009-10-07T06:35:58Z

Well, my speculations actually came true and even sooner and on a much larger scale than I have expected: Kindle 2 World version is available for pre-orders and will start shipping on Monday, October 19. Generally, International version of Kindle 2 is identical to the one that was released in February, except that it uses [...]

Эти пользовательские интерфейсы / David Pogue «Simplicity sells»

2009-09-24T01:46:45Z

Простая и гениальная лекция! [ENG]
c титрами есть тут — www.ted.com/talks/david_pogue_says_simplicity_sells.html

Трибуна Ашманова: про Гугл ОС, империи зла и прочую rocket science

2009-08-06T16:41:00Z

Не так давно в прессе и сети поднялся чудовищный шум по поводу объявления Гуглом о проекте собственной операционной системы. Я уже где-то про это пару раз высказывался в дискуссиях, поэтому хочу здесь суммировать свои разрозненные и довольно очевидные мысли. Тем более, что на Роем.ру наблюдается явное летнее торможение, так что некоторое количество флеймообразующих провокаций и наездов не помешает.

Империя добра не может не победить?

Ликование в блогах и каментах в Рунете по поводу гугловской ОС какое-то чрезмерное и напоминает худшие проявления фанатизма сторонников Apple и других lovemarks. Всем порядочным и разумным людям давно совершенно ясно, что у Гугла не только лучший поиск, что не только он вот-вот сожрёт Яндекс, не только то, что у него лучшая почта всех времён и народов, но и то, что уже начался закат Микрософта. Что Гуглу стоило наконец пальцем шевельнуть и подлому Микрософту конец.
Фанаты Империи добра даже не обращают внимания на то малозначительное обстоятельство, что это сообщение от Гугла - только о том, что в 2010 году что-то такое будет Гуглом выпущено, а пока у него - ничего нет.
Им ясно, что Гугл уже победил. Просто посредством пресс-релиза. Это ж Империя добра и она круче всех!
Обсуждать что-то на таком уровне эмоций бессмысленно. А на уровне спокойного наблюдения и здравого смысла – можно.

Почему ОС?

Один умный человек как-то сказал мне, что Интернет там или нет, Веб 2.0 или Веб 3.0, а судьба компьютерной индустрии и Интернета всё равно решится на десктопе. Потому что десктоп – это и есть то, что видит пользователь, то место, где для него возникает и офис, и почта, и игрушки, и социальная сеть, сам Интернет. Так что тот, кто контролирует десктоп (ну или то, что идёт ему на смену, нетубки, мобильники, букридеры и т.п.) – тот и будет контролировать Интернет.
Пока контроль над десктопом - у Микрософта. Поэтому Гуглу ничего не остаётся, как рано или поздно ступить на площадку Микрософта и бросить там ему вызов. Вот Гугл наконец это и сделал.

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

Специализация компаний

Вспомним о специализации компаний, и как она влияет на бизнес. На уровне стартапа и роста бизнеса в первые 5-7, даже 10 лет развития бизнеса узкая специализация является безусловным благом. Эту специализацию (фокусирование) категорически советуют маркетологи и венчурные капиталисты. Выбери один продукт, один ключевой показатель эффективности и бейся за него. Это выгодно и сточки зрения маркетинга, и с точки зрения концентрации ресурсов, вообще по многим причинам.
Этот путь прошли и МС, и Гугл. Когда-то (25-30 лет назад) МС был компанией операционной системы, а Гугл (7-10 лет назад) – компанией поисковой машины.

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

Микрософт сделал Офис, затем двинулся в корпоративный софт, построил каналы, сделал Exchange, MS SQL Server, вышел в Интернет и так далее. А Гугл стал на 7-8 году жизни превращаться в портал, купил видеохостинг, сделал почту, корпоративный поисковик и тулбар, социальную сеть и т.д., и т.п.

Часто это расширение продуктовой линейки диктуется не соображениями эффективности бизнеса, а куражом, ощущением всемогущества. Компании хватает денег и человеческих ресурсов, чтобы стать "всем для всех". Почему ж не стать?

Пределы эффективного расширения продуктовой линейки

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

Например, Микрософт является гением совместимости, специалистом по созданию сложных инженерных систем, работающих на миллиардах компьютеров по всему миру. Офис, ОС, прочее - в этом поле.
Даже пропустив почему-то начало эры Интернета, МС быстро нагнал этот поезд, сделав браузер IE, потому что браузер – это тоже десктопный софт для миллионов пользователей. Это известная Микрософту магия.

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

Вообще исследовательский центр Microsoft Research, в задачу которого и входило развитие ИИ, по моему личному мнению - это гора, родившая мышь. Подавляющее большинство заявленных задач ИИ в Microsoft Research не было решено, несмотря на огромные денежные вливания, хотя кое в чём - в базах данных (для MS SQL)и других более инженерных задачах они продвинулись. Почему-то ИИ Микрософту категорически не даётся (не давался?). Что-то не так с его компетенцией в этом месте.
Похоже, здесь лежит естественная граница компетенции МС, как компании. Может быть, они её наконец преодолели с выпуском поисковика Бинг, не знаю. Посмотрим.

Гугл, напротив – чемпион именно по ИИ, релевантности, обработке текстов и т.п. Но у Гугла при выходе в высшую лигу тоже возникло чувство всемогущества и зуд расширения. Желание стать "всем для всех". В первую очередь из компании одной поисковой строки Гугл стал производителем бесплатной почты, социальных сетей и прочего. Но успехи даже в этой "портализации" - очень скромные, по-моему.

Да, фанаты Гугла будут готовы умереть за то, что их дама сердца, Gmail, всех прекрасней. Но вот сколько у неё пользователей? Я вот не знаю и мне это очень подозрительно (не в том смысле, что я ленивый и невежественный, это-то ясно, а в том смысле, что если их было бы ну вот прямо очень много – об этом бы трубили на всех углах и я бы тоже знал).
В России у Gmail пока столько пользователей, сколько у нас может быть гиков, то есть техноманьяков. А именно, в несколько раз меньше, чем у почты Яндекса, и на полтора порядка меньше, чем у Mail.ru. По-моему, Gmail нельзя пока назвать успехом. С социальными сетями у Гугла вообще явный провал. Все большие сети возникли вне Гугла, Гугл-Видео не взлетел, пришлось купить YouTube, а свой проект закрыть и так далее.

Всё же портализацию Гугла остановить нельзя, туда идут все, и им придётся в этом тоже стать специалистами. Где же лежит естественная (и невидимая) граница компетенции Гугла?

Производство ПО – особый бизнес

Почему-то успешные интернетчики очень хотят быть также разработчиками ПО. Вероятно, тут сказывается высокая престижность этого занятия, которое с 80-х годов и до прихода Интернета было предметом восхищения и поклонения. Это же круто – производить крутое программное обеспечение. Этим на заре эры компьютеров занимались самые понтовые, конкретные пацаны. Билл Гейтс, Билл Джой и другие титаны.

Но это – совершенно другой бизнес. Разработчики поисковой машины, грубо говоря, имеют дело с программой в единственном экземпляре. Если что-то не так, подбежал, проволочку подогнул, гайку подкрутил - и порядок. А пользовательское, отчуждаемое ПО живёт совершенно другими циклами, как только ты выпустил версию на рынок, ты не можешь ничего в ней подкрутить, исправить. Нужны поддержка, патчи, тестирование, планирование на годы вперёд, обратная совместимость версий и т.п.

Хуже всего – это совместимость с ПО и железом. Вот уж что не беспокоит Гугл или Яндекс как программный комплекс, как интернет-сервис – это совместимость, потому что платформу и программное окружение разработчики тщательно выбирают и настраивают сами.
А для пользовательского ПО необходима совместимость со всем зоопарком ОС, ПО, кодировок, языков и железа, который есть в мире. Сейчас производитель ПО должен иметь мощные тестовые лаборатории, построенные бизнес-процессы выпуска и тестирования. И компетенцию в совместимости.

Заметим, что великий Apple так и не решил этой проблемы: его ОС и ПО всегда существовали внутри тёплого ограниченного мирка собственного проверенного и отлаженного железа. Как результат – 5-10% рынка в течение десятилетий. И толпа фанатов, "думающих иначе". Стоило Apple спустя 20 лет наконец оскоромиться и допустить использование процессоров Интел, как рыночная доля Маков тут же резко подскочила. Вот что совместимость животворящая делает!

Тем не менее, несмотря на всё величие проблемы совместимости, Гугл уже несколько лет движется в сторону производства отчуждаемого ПО. Но здесь у него успехи пока очень скромные. Не буду перечислять все отчуждаемые продукты Гугла, помяну некоторые для примера. Устройство Гугл-мини – продукт для рынка корпоративного поиска. По-моему, провал. Этому рынку уже 20 лет, там есть сильные игроки типа FAST, Autonomy, Verity, Convera. Где там среди них Гугл? Да пока вообще-то нигде. И оглушительный поисковый бренд не помогает, что удивительно!
И понятно почему: потому что в корпоративном мире решают до сих пор рекомендации, кейсы, канал и внедренцы. А это нужно строить годами.

Программа десктопного поиска от Гугла – насколько популярна? Все мои знакомые (гики), поставившие её с восторгом, постепенно снесли – из-за совместимости. Какие-то конфликты с ПО, Аутлуком, антивирусами – короче говоря, опять совместимость. Новый браузер Хром от Гугла – очевидно, явный провал. При таком интернет-бренде и существующих возможностях раскрутки получить 1-2% рынка – это провал. Новая ОС Андроид для мобильников – медленный старт, телефоны пока не дешевле, ничем по сути не лучше. Может, это не провал – но и не успех. Пока.
Вот это слово "пока" – ключевое. Но об этом ниже.

Для полноты картины упомяну такие же опыты Яндекса по выходу на рынок отчуждаемого ПО. Спамооборона как продукт – где она? Ну, как-то продаётся. Продукт номер 2 на русском рынке с большим отрывом от лидера. Зарабатывает доли процента от оборота Яндекса. На мой взгляд - неудача по соотношению затраты/результат.

Яндекс.Сайт (он же Яндекс.Сервер), отчуждаемый сервер для поиска по сайтам – где он? После нескольких лет в попытках продавать продукт он был в итоге сделан бесплатным. Да, он стоит на нескольких сотнях или даже тысячах сайтов Рунета. И в чём смысл? Тулбар Яндекса – хорошая вещь, но сколько их роздано? Максимум несколько сотен тысяч. Для такого бренда – мало. С десктопным поисковиком дело и того хуже (как и у Гугла, я думаю). Мне лично не нравится также и история с Punto Switcher, который на мой взгляд после покупки Яндексом не только не развился, но ухудшился.

Итак, между производством интернет-сервисов и производством отчуждаемого ПО лежит пропасть. Есть ли у Гугла (или Яндекса) компетенция для её преодоления – неизвестно. Пока попытки не очень удачные.
Но теперь Гугл сделал самую главную заявку на матч десятилетия – на перепрыгивание этой пропасти одним могучим прыжком: на создание полноценной десктопной ОС. Ну и базирующегося в сети офиса к ней.

Производство ОС – ещё более особый бизнес

Что решает в бизнесе ОС? Основное – это опять совместимость. С момента, когда стартовал бизнес Микрософт, порог входа на этот рынок стал очень высоким. Железа и ПО сейчас столько, что все комбинации того и другого невозможно ни оттестировать, ни предусмотреть. Нужно иметь гигантские тестовые лаборатории, инфраструктуру, понимание, чувство совместимости, ключевую компетенцию в этой сфере, процедуры быстрого реагирования на ошибки. Пока единственный, кто это асилел – Микрософт. Да и Микрософт, естественно, сам по себе уже - порог.

Есть ли такая компетенция у Гугла? Пока, очевидно, нет. Пример выкатывания браузера Хром наглядно показывает, что пока в Гуле не очень понимают, что такое оттестированный релиз, совместимость версий, патчи и т.п. Сейчас гуглеры, наверно, чему-то уже научились – но выкатка и поддержка ОС представляет собой следующий класс в этой школе, которую Микрософт уже давно окончил.

Чтобы долго не обсуждать различные проблемы ОС (их здесь уже обсуждали многократно), упомяну только, что в пресс-релизах Гугла, анонсах в его блоге вообще не упоминается проблема драйверов к периферийным устройствам (или я не заметил). Это меня поразило больше всего. Ведь даже в Линуксе эту проблему пока не научились решать в полном объёме, что и удерживает Линукс в нише ОС для гиков и серверов. Что будет делать сетевая ОС Гугла, когда нужно будет распечатать документ на принтере или всосать видео с камеры? Я пока не понимаю, как они собираются решать эту проблему. Выходить в Windows в подложке? А ведь это до сих пор во многих случаях является довольно-таки рабочим рецептом для Линукса, которому уже два десятка лет!

А ведь есть ещё второй фактор, ключевой для распространения ОС: канал. Быстрое распространение ОС начинается тогда, когда её принимает канал. Возможно, Гугл над этим работает (даже наверняка, есть сообщения о контрактах со сборщиками компьютеров).
Но по существу канал сейчас – всё-таки у Микрософта. Микрософт ведь тоже не спит. Он тоже планирует. А Микрософт, он как тот Вовочка из анекдота, который если что сказал – то сделает.
И Микрософт шевелится довольно энергично, причём на своей площадке. Только что Болмер рассказал о планах дать Exchange, Windows и Office в формате SaaS, про создание хостинговых центров Микрософт для хостинга приложений. И канал, и потребители реагируют позитивно. А канал строится и завоёвывается годами. Как выбить МС из него?

Конечно, и совместимость, и канал – проблемы в принципе решаемые. Вопрос только в усилиях, сроках и деньгах. Я, собственно, не против идеи, что Гугл рано или поздно что-то себе здесь отвоюет. Мне не нравится пиар в стиле театрального напрягания бицепсов перед боем.

Плохая манера пиарить ДО

Зачем вообще Гугл объявляет о том, чего пока нет? Он ведь никогда так раньше не делал.
Я лично выработал для себя правило: если проект активно пиарится до старта – это очень плохая примета. Скорее всего, будут проблемы. Конкретные пацаны сначала делают, а потом говорят. Понятно, что если не пиарить новую ОС, то труднее договориться со сборщиками и ОЕМщиками. Трудно уговаривать их, сообщая на ухо про будущий продукт, да и утечка будет всё равно. Но всё-таки как-то неаккуратненько.

Важное слово "пока"

Я лично вполне верю в возможность успеха Гугла в сфере ОС. Я не верю в быстрые успехи. Ну вот как можно рассчитывать, что юное дарование без известных турнирных побед сразу выиграет в шахматы у гроссмейстера, чемпиона мира? Я бы не рассчитывал. Даже если юное дарование всех в мире рвёт в нарды.

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

Представим себе, что у вас есть холдинг по производству атомных подводных лодок. Это очень большая структура, десятки институтов, заводов, верфей. Сотни тысяч людей.
Всё работает как часы. Денег полно, люди сильные. И вот вы мне говорите, что всё, пора заниматься космонавтикой, у вас полно ресурсов и знаний, и через полгода, максимум год вы запустите луноход на Луну.

Позвольте мне вам не поверить. Ну да, ваш холдинг – крутая штука, одних подъездных путей, цехов и складов на среднюю европейскую страну хватит. Опыт, деньги, интеллект, это я всё понимаю.
Но при чём здесь луноход? Это же совсем из другой сказки. Сначала вы наймёте астрономов, математиков, химиков - специалистов по топливу, потом через 3-4 года у вас взлетит первое "изделие", переломится пополам и упадёт на землю. Потом ещё через несколько лет таких запусков и падений вы выведете первый спутник на орбиту. А там и про луноход можно будет подумать.

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

А во "всё, победа, через месяц у Хрома будет 20%" , как тут в сети бились об заклад – не верю.
По сути у Гугла сейчас есть только похвальба. Комплекс полноценности, иллюзия всемогущества. Вот когда он повозится на десктопе несколько лет, узнает, какой зоопарк железа надо поддерживать, построит каналы, тестовые лаборатории, бизнес-процессы, рекрутирует армию независимых внедренцев и ОЕМ-партнёров, тогда доля рынка может начать медленно ползти вверх. Но ведь и МС не будет сидеть сложа руки.

Единственное, на что можно всерьёз рассчитывать - это уход Гейтса от дел. Если бы Гейтс остался у руля, шансов не было бы совсем, а так – кто знает. В Болмера я верю меньше, он все-таки чистый бизнесмен, а не гениальный разработчик и бизнесмен в одном лице, и о совместимости знает гораздо меньше, чем о канале... Но и у Гугла нет бойца, сравнимого по силе с Гейтсом, для борьбы на десктопе, по-моему.

Ну, посмотрим. В ближайшие пару-тройку лет на рынке ОС точно ничего не произойдёт тектонического. Так мне кажется.

!Вася Треугольник "Sales-Account-PM" в бизнесе студии
!Alter Ego Треугольник "Sales-Account-PM" в бизнесе студии
!Забавно!!!! Треугольник "Sales-Account-PM" в бизнесе студии
!Вася QSOFT признает результаты нагрузочных тестов «1С-Битрикс: Управление сайтом» некорректными
!Alter Ego Треугольник "Sales-Account-PM" в бизнесе студии

8 мая в пультовой детектора ATLAS

2009-06-16T22:12:00Z

В ленте новостей детектора ATLAS (ATLAS e-News) рассказывается о поучительной истории, которая случилась в пультовой детектора ATLAS 8 мая. Детектор работал в нормальном режиме, софт собирал данные и рутинно их обрабатывал, а потом вдруг софт упал. И целые сутки его не могли поднять. На графике видно, что количество процессов резко росло при каждой попытке перезапустить систему.

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

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

Stephen Wolfram’s Introduction to Wolfram|Alpha

2009-05-13T15:03:01Z

Building the ultimate computational knowledge engine is a highly ambitious and long-term project. The Wolfram|Alpha that you will get to start exploring next week is really just the beginning. Still, there are a lot of ways that you might use Wolfram|Alpha.

In this screencast, Stephen Wolfram gives a quick introduction and demo of today’s Wolfram|Alpha.

Читай код

2009-05-03T12:05:16Z

Эту статью я написал по просьбе организаторов специально для сайта конференции software people. Опубликована здесь: http://www.softwarepeople.ru/press/articles/09/

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен. Однако, возникла некоторая загвоздка – CQG не являлось приложением баз данных, основанном на комбинации готовых сторонних технологий, таких как MS SQL сервер, Visual Basic, Delphi, JavaScript, и 1C – к которым я привык. Меня потряс объем приложения – почти 50 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.

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

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

В этот раз, перед тем, как что-либо писать, я предусмотрительно показал свой предварительный дизайн (подход к решению проблемы) Толу Корину (Tal Korin), автору и главному архитектору данной системы, и он направил меня в правильном направлении. У Тола ушло на это 5 минут. Это был первый случай, когда я сам инициировал дизайн-ревью (не зная, как оно называется), и был рад найденным у меня проблемам. После успешного выполнения данного задания я поступил в распоряжение Тола Корина, поскольку, с его слов и к моему безмерному удивлению, я оказался одним из немногих, кому пошли впрок лекции по архитектуре.

Каких-либо иллюзий на свой счет, меж тем, к тому моменту у меня уже не осталось – я понял, что цена всем моим знаниям, университетскому образованию, и опыту – ломаный грош. Меня поражал простой факт – я был объективно образован в Computer Science гораздо лучше Тола, и _знал_ больше. При этом, и, после некоторого опыта работы, я был в этом абсолютно уверен – я бы не смог спроектировать и реализовать такую систему за год, как это десять лет назад с одним помощником сделал Тол. Сложность системы явно превосходила мои возможности - я бы по ходу работы закопался в деталях. И уж тем более, у меня не получилось сделать систему так гибко, чтобы она прожила 10 лет, и была до сих пор адекватна ситуации.

То есть, до меня начало доходить, что есть нечто очень важное, что совершенно перпендикулярно университетскому образованию, чего нас просто не учили даже замечать. Оно перпендикулярно «дизайн-паттернам» и книгам по ОО проектированию. И оно, это нечто, у Тола есть, а у меня – нет. Если мои знания не могут мне помочь сделать такую систему – то много ли они стоят? Понимание и знание требуется для действия, ни для чего другого – это не китайская декоративная ваза.

С этого момента я начал внимательно наблюдать за Толом, изучать его решения и подход, и твердо решил разобраться, что же это такое за неуловимая штука, которой я не понимаю. То есть, я «записался в ученики», и Тол с удовольствием взял роль наставника. И за несколько лет Тол сделал меня инженером, показав мне на практике, что это такое, и за что я ему буду всегда благодарен.

По большей части это напоминало дзен, когда вам дают задание, разрывающее мозг, вроде хлопка одной ладонью, и через некоторое время вы неожиданно ловите просветление. Удивительный опыт. Вот один небольшой пример, на что это было похоже.
- Тол, скажи, а как работает вот эта штука.
- Влад, вот этого я на самом деле не знаю. А ты почитай код, и разберись!
- Тол, ты издеваешься надо мной?! Здесь пятьдесят мегабайт этого гребанного недокументированного кода! Ты знаешь все Тол, и это ни для кого не секрет.
- Хорошо, смотри, – не стал спорить Тол, - Я тебе говорю – я не знаю, и поэтому я должен сам почитать код, чтобы ответить на твой вопрос. Поэтому, я открываю код.
Тол открывает правильный файл в одну попытку, продираясь через файловую систему, не пользуясь класс-браузером, мотает файл в правильную середину.
- Так. Ты сказал, вот эта фигня? Вот, открыл. Так… Тебе нужен вот этот метод. Читаем. Вот, смотри, он вызывает вот этого парня (так Тол называл классы и объекты – look – now this guy tell that guy to do this thing). Видишь? Вот, происходит тут то-то и то-то. Все просто.
- Спасибо, Тол! Теперь все ясно. А говорил – не знаешь!
- Я тебе говорю – код читай, блин! Все то же самое ты можешь сделать сам!
- Тол, ну в нем же нихрена не понятно без документации, - сказал я, будучи совершенно уверен, что я не смогу сделать того же сам. Происходящее напоминало ловкий фокус.
- Тебе, чтобы читать код, нужна документация? Прости – какая?
- Ну, там, диаграммы классов, например.
- У нас была одна, вроде, составленная лет пять назад. Она сейчас, мягко говоря, не соответствует действительности. Сам понимаешь, у нас 50 инженеров, и разработка идет очень активная. Но если ты уверен, что она тебе поможет, я могу поискать, – участливо смотрит на меня Тол, - ну так что, искать?
- Не, устаревшая, мне, пожалуй, не поможет, - подумав, ответил я, - это ж я все равно должен весь код изучить, чтобы понять, где ей можно доверять, а где нет.
- На самом деле, я не уверен, что тебе сильно поможет даже новая, и поэтому я тебе и говорю: код – лучшая документация! – терпеливо разъясняет Тол, - Она _всегда_ актуальна, и _никогда_ не устаревает, помимо того, что более информативна чем диаграмма классов, конечно.
- Хорошо, я понял, а может, ты мне еще объяснишь, вот в этом месте как работает…
- Нет. Это ты мне объяснишь, после того, как прочтешь. Мне как раз надо скоро будет туда правки вносить. Давай, парень, я не тебя рассчитываю. Иди - читай код.
- Хорошо, Тол, – обреченно сказал я, и пошел читать код.

Да, надо сказать, я тогда немного обиделся на Тола, я думал, что он нифига не понимает. И долгое время считал, что он был не прав. Как-то года через три ко мне подошел коллега, с вопросом. Я был утомлен от работы, голова соображала вяло. К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

- Слушай, Влад, не поможешь, объясни, как работает вот эта подсистема?
Я вяло поднимаю глаза на коллегу, вижу безнадежность в его взгляде, тяжело вздыхаю, и решаю ему помочь. Хоть я ничего и не понимаю в этой подсистеме – так, рядом проходил.
- Хорошо, смотри, – тут я «вслепую», без всяких класс-браузеров, продираюсь к «правильному» файлу, открываю его, и поиском нахожу нужный метод, - видишь, вот здесь что происходит?

Я читаю код, без труда восстанавливая логику поведения и структуру программы в уме, и одновременно простыми словами объясняю это коллеге. Тут у меня в голове что-то перещелкивает, и я с изумлением вспоминаю наш разговор с Толом трехлетней давности, сознание у меня как бы раздваивается, и я наблюдаю за собой со стороны.

- Вот, видишь, как все просто, - заканчиваю я. И к своему чудовищному удивлению добавляю, то, что надо сказать, потому что это правда:
- А вообще - читай код. Код – лучшая документация. Ты вот думаешь, я разбираюсь в этой подсистеме? Нет, я этот код вижу в первый раз, так же как и ты.
- Но этот код совершенно не документирован! Диаграммы хоть какие-нибудь бы!
- Смотри, - говорю я улыбаясь, окончательно осознавая, что Тол в очередной раз, как и всегда, оказался прав, - вот я запускаю Rational Rose, где у меня всосана вся наша система в режиме reverse engineering, и бросаю на чистый лист эти пять классов. Видишь? Вот тебе свежая, актуальная диаграмма. Какой смысл тратить усилия на документирование того, что устаревает за год, и может быть в любой момент восстановлено за пару минут? Если она тебе сильно поможет, я сейчас ее тебе распечатаю. Распечатать?
- Да нет, пожалуй, - задумчиво отвечает коллега, рассматривая диаграмму. Ясности она не добавляла.
- Вот. Диаграммы не стоят ничего, ценны мыслительные процессы, происходящие у тебя в голове в процессе их составления. Поэтому я и говорю: код – лучшая документация. Читай код.

Разумеется, Тол хотел мне показать не только и не столько практическую бесполезность проектной документации, как это могло показалось на первый взгляд. Философия "код - лучшая документация" дает гораздо большее, чем отсутствие документации. Это необходимое ограничение, только приняв и осознав которое, и в результате - рассчитывая только на свои силы, понимая - что код - основной источник информации, его нельзя боятся, с ним надо столкнуться в лоб, и этого не получится избежать, обойти, и перепрыгнуть, - можно достичь мастерства в reverse engineering и вообще понять, что это такое.

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

Толу на самом деле было все равно, есть документация или нет. В совершенстве владея reverse engineering, он в уме потрясающе легко умел переходить от кода к архитектуре, и наоборот. В результате, проектируя, он всегда детально представлял, в какой код превратятся его мысли, и поэтому был способен быстро прокручивать в голове огромное количество вариантов, отбрасывая "плохие". В его понимании, архитектор, не умеющий читать чужой код с "листа", и не пишущий своего - подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором - вопрос нескольких лет.

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

City Builder

2009-03-06T11:13:22Z

The beautifully crafted short above by Bruce Banit (via Kevin Kelly’s blog) depicts a fantastical yet believable world building interface, in a future that does not feel too far off from where Google Sketch Up is now. As if to prove that point, Stewart Brand sent over the below reference:

This virtual “Telematics City” was built by design firm Hook for a Lexus marketing campaign. The fantastic video linked above is a time lapse of the “building” of that city. I guess it’s like the man said…

“The future is here, its just not evenly distributed yet.” - William Gibson

And yet another Update: Wired is running a piece today on the physical city modeling that has taken place, and features one of the greatest treasures in the SF Bay Area, The Army Corps of Engineers Bay Model in Sausalito.

Friday Fun: The world in 2019

2009-03-20T11:48:00Z

Microsoft offers this view of the world of technology in 2019. Looks like we'll have easier interfacing and more handheld computing devices. And good news! if you watch carefully at 0:35 you'll see that the Pragmatic Marketing Framework is still the standard for product management a decade from now. :-)

How to be a program manager

2009-03-09T18:16:23Z

Having a good program manager is one of the secret formulas to making really great software. And you probably don’t have one on your team, because most teams don’t.

Charles Simonyi, the brilliant programmer who co-invented WYSIWYG word processing, dated Martha Stewart, made a billion dollars off of Microsoft stock and went into space, first tried to solve the Mythical Man Month problem of organizing really big software teams by creating one super duper überprogrammer writing the top-level functions, while handing off the implementation of the lower-level functions to a team of grunt junior-programmers as needed. They called this position program manager. Simonyi is brilliant, but this idea, not so much. Nobody wanted to be a grunt junior programmer, I guess.

For more on the history, read William Poundstone’s How Would You Move Mount Fuji?

Jabe Blumenthal, a programmer on the Mac Excel team in the late 80s, recycled the title for a different job. He had noticed that software development was getting so complicated that none of the programmers had the time to figure out how to make software that was either usable or useful. The marketing team was ranting and raving about customer needs and nobody had time to talk to them or translate their MBA-speak into actual features. There was a lot of product design stuff that took a lot of work: talking to users, running usability tests, reviewing competitive products, and thinking hard about how to make things easier, and most programmers just didn’t have the time (nor were they particularly good at it). Blumenthal took the title “Program Manager,” but reinvented the job completely.

What does a program manager do?

Henceforth, a program manager would:

Design UIs
Write functional specs
Coordinate teams
Serve as the customer advocate, and
Wear Banana Republic chinos

On small products, you might just have one program manager, but on larger products, you would probably have more than one. Each can be responsible for some subset of the features. A good rule of thumb is that it takes about one program manager for every four programmers. If you’re having trouble dividing up the work, one approach I learned from Mike Conte is to divide up the product according to user activities. For example, Twitter could be divided into four user activities:

Registering and getting started
Posting messages and reading replies
Configuring your account
Searching for news

Tyler Griffin Hicks-WrightMy first program management assignment at Microsoft was on Excel, working on the user activity called “customization,” i.e., scripting and macros. The first thing I had to do was figure out what customers needed, which I did by talking to as many customers as I could until I started to get kind of bored because I kept hearing the same thing. I spent a lot of time talking to the development team to figure out what would be possible and reasonable to implement in a single 18 month release, and I spent a lot of time talking to the Visual Basic team to see if they could supply a compiler, code editor, and dialog box editor that could be used in Excel for our macro language. I also had to talk to Apple, which was developing their own universal macro language called AppleScript, and the other application teams at Microsoft, mainly Word, Access, Project, and Mail, who generally did whatever Excel did. Most of this process consisted of talking. Meetings, email, phone calls. I am scarred for life from this, and now cower in my office in fear that the phone will ring.

The second step was writing a vision statement: sort of a broad document that said, this is how Visual Basic would work in Excel, this is what some sample macros would look like, these are the major pieces we would need to build, and this is how it would solve customers’ problems. When that didn’t generate too many objections, I started working on a much more detailed spec, which explained, down to the smallest detail, how everything looked to the user.

This was a functional spec, not a technical spec, which means, all it talked about was what the user saw, not how it was implemented. (Read all about functional specs here.) A program manager doesn’t care how the development team implements things internally. As I sent chapters of the spec to Ben Waldman, the development lead, he and his team sat down and figured out what they had to do internally to make it work. They came up with a rather brilliant and very compact table that mapped the object-oriented interface I was defining onto internal Excel functions, but that really wasn’t my business. I didn’t know too much about Excel internals and didn’t really know how things should be implemented.

Truth be told, I didn’t know anything about anything. Fresh out of college, I didn’t have enough experience to develop the code, test the code, write the documentation, market the product, or do the usability tests. Luckily, Microsoft had seriously experienced gurus in each of those positions, who taught me everything I know today, and who did the real work of producing an awesome product. For example, I knew that users would want to copy the value of a spreadsheet cell into a variable:

x = [A1]

had to work. The trouble was that a cell could hold a number or a string, but Basic was early bound… you had to DIM x as an Integer, Float or String before you could use it.

Basic had to get some kind of dynamic types, but I wasn’t smart enough to figure out how to do that. Didn’t matter. Tom Corbett, a programmer on the Visual Basic team, figured out how. And thus Variants and IDispatch were born, and Basic became a dynamic language with what you kids now call “duck typing”. The point being, my job wasn’t necessarily to solve problems, it was to figure out what customers needed and make sure that programmers figured out how to solve them.

Once the spec was finished and the development team got down to work, I had two responsibilities: resolving any questions that came up about the design, and talking to all the other teams so that the developers didn’t have to. I met with the testers explaining how things were supposed to work and helping them plan how to test everything. I met with the documentation team, making sure they understood how to write a good tutorial and reference for Excel Basic. I met with localization experts to figure out a localization strategy. I sat down with marketing to explain the marketing benefits of VBA. I worked with usability experts to set up usability tests.

A program manager does go to a lot of meetings, but doesn’t produce much other than that written spec, which is why as a twerp fresh out of school I was still able to do the job. You don’t have to be a 14-year veteran programmer to work as a program manager (in fact, with 14 years of programming experience, you might know too much to be a good user advocate.)

Conflict

Tom Chi and Kevin ChengLacking a program manager, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense IF YOU’RE A VULCAN (cf. git). The best programmers are notoriously brilliant, and have some trouble imagining what it must be like not to be able to memorize 16 one-letter command line arguments. These programmers then have a tendency to get attached to their first ideas, especially when they’ve already written the code.

One of the best things a program manager can add to the software design process is a second opinion as to how things should be designed, hopefully one that is more empathetic to those RETARDED USERS with their pesky mental feebleness requiring that an application be usable without reading the man page, writing a custom emacs-lisp function, or translating numbers into octal in your head.

A good program manager will come with her own ideas for how the UI should work, which might be better, or worse, than the developer’s idea. And then there’s a long debate. Typically, the program manager wants something simple and easy to understand for the users, featuring a telepathic user interface and a 30" screen that nonetheless fits in your pocket, while the developer wants something that is trivial to implement in code, with a command-line interface (“what’s so unusable about that?”) and Python bindings.

One of the most monumental debates I remember from the Excel 5 project was between a developer who wanted pivot tables to float on the drawing layer above the spreadsheet, and the program manager, who insisted that pivot tables live right in the cells on the spreadsheet. This debate went on for a really, really long time, and eventually, the program manager prevailed, but the final design came out much much better than any one individual’s design would have been.

To make sure that the debate happens respectfully and on a rational basis of facts, it’s absolutely critical that the program managers and developers be peers. If developers report to the program manager, at some point during the debate the program manager is going to get sick of the whole thing and just say, “OK, enough talking, now we do it my way.” When they’re peers, this can never happen. It’s a little bit like courts of law: we don’t allow a lawyer for one side to be the judge, and we work on the theory that the truth is most likely to be uncovered through a process of debate between equals. The debate can only be a fair one if neither side has an unfair advantage.

This is an important point, so if you were daydreaming about Sally in 11th grade, wondering where she is now, snap out of it. She’s a biotherapist in Scottsdale, and a Republican. Now pay attention. Programmers can’t report to program managers which means, among other things, that the development lead, or the CTO, or the CEO, can’t be the person who writes the specs.

The number one mistake most companies make is having the manager of the programmers writing the specs and designing the product. This is a mistake because the design does not get a fair trial, and is not born out of conflict and debate, so it’s not as good as it could be.

I learned this the hard way. At Fog Creek Software, I did a lot of the program management myself, and it was a constant battle to remind people that they were supposed to argue with me when I said wrong things. We’re not a big company but we are finally big enough to have real program managers now, Dan and Jason, and the programmers love arguing with them.

Of course, when programmers are peers of the program managers, the programmers tend to have the upper hand. Here’s something that has happened several times: a programmer asks me to intervene in some debate he is having with a program manager.

“Who is going to write the code?” I asked.

“I am…”

“OK, who checks things into source control?”

“Me, I guess, …”

“So what’s the problem, exactly?” I asked. “You have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?”

You see, it turns out that this system puts the burden on the program manager to persuade the programmer, because at some point, the program manager runs the risk that the programmer will give up and just do whatever the heck the programmer feels like. Thus, being effective as a program manager means you have to (a) be right, and (b) earn the respect of the programmers so that they concede that you’re right.

How do you earn this respect?

It helps, as a program manager, to be pretty good at coding yourself. This is unfair. Program managers aren’t supposed to write code. But programmers tend to respect programmers a lot more than non-programmers, no matter how smart they are. It is possible to be an effective program manager without being a coder, but the burden of earning the respect of the programming team will be higher.

flip the bozo bit v. Decide that someone is a clown, and stop listening to them.

The other way to earn the programming team’s respect is to demonstrate intelligence, open-mindedness, and fairness in any debates that come up. If a program manager says dumb things, the programmer might flip the bozo bit on them. If a program manager becomes personally or emotionally attached to a certain way of doing things, to the point at which they’re being unreasonable, they’re going to lose a lot of credibility… both sides, but especially the program manager, need to be emotionally detached from the debate and willing to consider new evidence and change their opinions when the facts merit it. Finally, if a program manager is seen as playing politics, having private meetings with the boss or trying to divide-and-conquer to win a debate instead of debating on the merits, they’re going to lose a lot of trust of the programmers.

And when a program manager loses the programming team’s trust, it’s over. They’re not going to be effective. The programmers are going to tune them out and do whatever they want anyway. This leads to worse code and wasted time, since not only are you paying an ineffective program manager a salary, but that ineffective program manager is calling meetings and soaking up everybody else’s time even though they’re not really making the code any better.

Specs? Really? That’s so unagile

There are so many development organizations where specs are a monument to mindless bureaucratic paperwork that entire movements sprung up organized around the idea of not writing specs. These people are misguided. Writing a functional specification is at the very heart of agile development, because it lets you iterate rapidly over many possible designs before you write code. Compared to code, a written spec is trivial to change. The very act of writing a specification forces you to think through the design you thought you had in your head, and helps you see the flaws in it quickly so that you can iterate and try more designs. Teams that use functional specifications have better designed products, because they had the opportunity to explore more possible solutions quickly. They also write code faster, because they have a clearer picture when they start of what’s going to be needed. Functional specifications are so important one of the few hard and fast rules at Fog Creek is “No Code Without Spec.”

The exact form the functional specification takes may vary. All a functional specification has to do is explain how the program will behave. It doesn’t say anything about how the code will work internally. You start at the highest level: a vision statement, no more than one page explaining the gist of the new feature. Once that’s nailed down, you can develop storyboards… mockups of the screens showing the user’s progression through the application, with detailed notes showing how they work. For many types of functionality, especially UI-heavy functionality, once you have these storyboards, you’re done. That’s your spec. Jason Fried, you can go now.

To learn how to write good functional specifications, read my four part series. If you want to see a typical spec I wrote, you can download the full Fog Creek Copilot spec.

For more complex functionality with hidden behavior that’s not expressed in the UI storyboards, you’re going to want more details written down. In any case, the very act of writing down a spec helps you discover problems, conflicts, and design issues long before the first line of code is written, so when you do write the code, you have far fewer unexpected issues popping up which might force a rewrite or, worse, a suboptimal design.

How do you learn to be a Program Manager?

Mostly, becoming a program manager is about learning: learning about technology, learning about people, and learning how to be effective in a political organization. A good program manager combines an engineer’s approach to designing technology with a politician’s ability to build consensus and bring people together. While you’re working on that, though, there are a few books you should read:

As far as I can tell, Scott Berkun’s book Making Things Happen is the only book that’s been written that pretty much covers exactly what a program manager has to do, so start with that. Scott was a program manager on the Internet Explorer team for many years.

Another big part of the program manager’s job is user interface design. Read Steve Krug’s Don’t Make Me Think, then my own book User Interface Design for Programmers.

Finally, and I know it sounds cheesy, but Dale Carnegie’s 1937 book How to Win Friends & Influence People is actually a fantastic introduction to interpersonal skills. It’s the first book I make all the management trainees at Fog Creek read, before anything else, and they always snicker when I tell them to read it, and love it when they’re done.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

Небо в движении

2008-12-31T15:19:00Z

Небо в движении -- шикарный видеоролик, просто зачаровывает.

Подсмотрено на Астронете.

2008-12-26 - Мысль дурака дискретна

2008-12-28T16:54:14Z

Букв примерно: 13200 ("Дурак мыслит спинным мозгом, самыми простыми категориями: добро/зло, хуево/пиздато, полезно/вредно, рай/ад, положительная энергия/отрицательная энергия, враги/друзья, ересь/святость и так далее...") .

Сказка про инженера, менеджера, и медведя

2008-11-24T23:27:00Z

*** Курилка корпорации CQG. 2004 год.

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

- Кстати, парни, мы вот с вами все обсудили, все детали, а осталась самая малость. А вы подумали о том, что мы с вами будем делать, если нам так не повезет, и мы все-таки убьем кабана?
-?! - говорим мы с Барахтяном.
- Вы знаете, сколько весит кабан?
- Сколько? - с подозрением спрашиваем мы.
- Здоровый кабан, на которого мы с вами собрались охотится, весит более 300 килограм. И как мы его будем тащить? А?
- Ерунда! - с энтузиазмом говорит Барахтян, - мы приедем на Ниве с лебедкой, зацепим его, и отвезем куда надо!
- А вы знаете, что кабана сначала надо подвесить на дерево...
- Слыш, Борис, да он сцуко весит больше нас троих вместе взятых!
- ...и освежевать его, чтобы с него стекла кровь!
- Да-а-а... - задумались мы с Барахтяном.

- Слыш, Борис, а может ну его нах, кабана, и все-таки пойдем на зайца, а?
- И где мы возьмем собаку? Я читал - на зайца без собаки никак.
- Не проблема. Я слышал, что собаку в охотхозяйстве выдают. В аренду возьмем.
- Да как бы нам, сцуко, не подстрелить случайно эту собаку, парни. Мы ж с вами охотники што песдец... - веско сказал Борис.

Все задумались...

*** В то же время, в офисе компании-разработчика ПО. Может быть, в вашей.

Подходит однажды менеджер к инженеру, и говорит:
- Пойдем охотиться на медведя.
- Ты что, с ума сошел? У нас в этом деле нет никакого опыта. Совсем-совсем. Ты когда-нибудь видел живого медведя? Я видел на фотографиях. У него зубы - во! Когти - во!! Я даже видел запись, где медведь своими когтями сносит незадачливому охотнику голову. Новый русский охотился на медведя с рогатиной. Его страховали двое парней с карабинами. Они не успели. Медведь движется сквозь лес на скорости до 40 км/час! Он снес парню башку просто взмахом своей лапы!
- Спокойно. Я обо всем позаботился, - уверенно отвечает менеджер, отметая возражения взмахом руки, - будет обеспечено профессиональное оборудование, и профессиональная поддержка. Все будет на высочайшем профессиональном уровне!
- Хм, точно? - неуверенно спрашивает инженер.
- Абсолютно! - уверяет менеджер.
- И когда приступим? - осторожно говорит инженер.
- Завтра. Встречаемся на большой поляне в лесу, в 10 утра.

***

Менеджер стоит на поляне в дорогом костюме, и держит в руке длинную палку. Он буквально излучает уверенность в себе, весь его вид говорит «я знаю, что я делаю, я делал это сотни раз».

- Ты же сказал, что будет профессиональное оборудование, поддержка?! Где профессионалы?! Где оборудование?! - спрашивает инженер.
- Спокойно! Все в порядке! Я обещал, что все будет на высшем профессиональном уровне? – говорит менеджер, легко подбрасывая палку и перехватывая ее движением фокусника.
- Да, - растерянно отвечает инженер.
- Вот. Так и будет, если мы будем следовать моему плану. Мы же команда, мы должны доверять друг другу. Пойдем.

Менеджер с достоинством подходит к берлоге, и со всей силы тычет в нору палкой. Тык. Тык. Из норы раздается рев, и оттуда выскакивает разъяренный медведь.

***

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

- Спокойно, все под контролем! – выдыхает менеджер, - Ты, наверное, думал, что мы бежим черти куда, не разбирая дороги?
- Да, примерно так я и думал!
- Нет. Все идет в соответствии с планом. Мы на графике.
- Профессионалы с оборудованием ждут нас в домике?
- Что-то вроде того. Говори поменьше, не надо сбивать дыхание. Тебе еще работать.

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

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

- Ну вот, - отдышавшись, ободряет инженера менеджер, - медведя я загнал. А технические детали ты теперь проработаешь сам!

*** Курилка корпорации CQG, 2004 год

- А что, Борис, может нам на медведя пойти?
- А вы, что, не знаете анекдот про медведя, парни? - смеется Борис, - что-то вспомнилось.
- Нет. Рассказывай!
- Ну, значит, спрашивает молодой охотник у бывалого, как правильно ходить на медведя. Тот, нервно дергаясь при слове "медведь", озирается по сторонам, и отвечает...

***

- ...ты главное не бойся. Подходишь к берлоге, палку, палку длинную с собой берешь, палку не забудь.
- Палка то зачем?
- Ты, главное, не бойся. Палкой тычешь в берлогу. Сильно тычешь.
- И что?! Оттужа же медведь выскочит!
- Ты, главное, не бойся. Медведь выскочит, а ты ему дерьмо возьми, и на морду намазывай, намазывай.
- А дерьмо-то откуда брать? - опешил молодой охотник.
- ты, главное, не бойся, дерьмо - будет, - с уверенностью говорит бывалый, еще раз нервно дернувшись, - ты ему дерьмо на морду, на морду намазывай...

*** Постскриптум

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

Экономический кризис на пальцах

2008-10-24T05:47:00Z

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

Тебе не кажется, что эта статья немного нарушает принцип Оккама?

Понимаешь, паршивые ипотеки сами по себе не являются настоящей причиной нынешнего кризиса. Если бы это было так, то стоимость того, чтобы с ним справиться, была бы не более $700 млрд, а порядка $40-50 млрд. чтобы помочь людям остаться в их домах и позволить пузырю недвижимости спуститься помедленней без особых последствий для экономики и общества.

Реальной проблемой были производные ценные бумаги основанные на этих ипотеках. Чтобы обяснить это не нужно математической теории или даже Excel'а. Хотя, признаю, в сердце всего была откровенная (и умышленная) математическая ошибка.

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

Итак, шансы, что мост обрушится - 50%. А значит, вы думаете, шансы потери каждой отдельной машины тоже 50%, и пока что вы абсолютно правы. Но! - думаете вы - шансы что по крайней мере 10% машин спасется должны быть значительно лучше! Нет, правда... если есть две машины с 50% шансом потери, то шанс что хоть одна из них уцелеет должен быть p1 + p2 - p1*p2 = 0.5 + 0.5 - 0.5*0.5 = 0.75, то есть 75%! А уж для 1000 машин результат будет еще лучше! Так что, если уцелевшая часть покроет стоимость, то вам будет хорошо, верно?

Вы уже заметили проблему? Зависимые события были представлены как независимые. Ошибка, за которую студент-первокурсник получает двойку каким-то образом оказались вполне простительной для руководителей компаний Уолл Стрита.

Если вы еще не поняли, позвольте обьяснить чуть подробнее. Итак, представьте себе что "флот" состоит из десяти машин, а владелец предложил вам их всех за 10% от честной цены. Если сосчитать вероятность, что хоть одна машина уцелеет, по формуле выше, то получится 99.95%, то есть одна уж точно уцелеет. И, соответственно, вы вступаете в игру, уверенные, что с вероятностью 99.95% вы денег не потеряете, и с хорошими шансами получите еще и доход. Вот только формула неверная, поскольку события зависимы. И вы по-прежнему теряете с вероятностью 50%.

Что ребята на Уолл Стрит сделали, это упаковали много плохих ипотек вместе и использовали кривую логику, описанную выше. Затем они выпустили (выпускали) облигации под 10% тех ипотек, которые уцелеют, и получили на них рейтинг ААА. Это очень важный момент - под облигации шли все ипотеки, и облигации "первого транша" получали обещанный доход с их всех, "второго транша" - то, что осталось от первого, и так далее. Таким образом "первый транш" выпускался по сути под "те, которые уцелеют". И никто даже и не думал о том, что они могут грохнуться все вместе. А затем, чтобы сделать жизнь интереснее, они же еще и выпустили вторичные облигации под эти облигации с плечом 1:10 (то есть на один дутый доллар изначальных облигаций они выпустили еще на десять дутых долларов вторичных). В целом этих облигаций выпустили в несколько раз больше чем валовой продукт всей планеты. Что при этом было проигнорировано, это то, что риск плохих ипотек - это не просто финансовое состояние разрозненных и многочисленных заемщиков, но еще и состояние общего и одного на всех пузыря недвижимости. Который - сюрприз! - должен быть лопнуть с вероятностью даже не в 50, а все 100 процентов, и все об этом отлично и заранее знали. Не говоря уж о том, что финансовое состояние заемщиков плохих ипотек не является таким уж независимым тоже. Один экономический кризис и...

Так что, как видите, никакой нужды в сложной математике или даже в Excel (хотя я и использовал его, чтобы подсчитать вероятность того, что уцелеет одна машина из десяти). С чем мы тут имеем дело - это жульничество и воровство, ничего такого, с чем не мог бы справиться хороший полицай-держиморда. К сожалению, ни Гринспен, ни Бернарке хорошими полицейскими не оказались.

---
Да-да, кросс-пост с персонального блога...