"Нет такой вещи, как бизнес."

"Так чего же мы боялись? Мы чувствовали себя уверенно в программировании, но нам
не хватало уверенности в том, что мы сможем заниматься загадочной и непонятной
нам вещью под названием "бизнес". На самом деле нет такой вещи, как "бизнес".
Есть продажи, реклама, определение потребностей людей, определение ценовой
политики, поддержка пользователей, оплата счетов, получение оплаты от клиентов,
обеспечение деятельности юридического лица, привлечение инвестиций и так далее.
А все вместе это не так сложно, как кажется, потому что некоторые задачи
(например, привлечение инвестиций или обеспечение деятельности юридического
лица) отнимают множество усилий, как у маленьких, так и у больших компаний, а
другие (например, продажи или реклама) требуют скорее энергии и воображения, чем
какой-то особой подготовки."

Пол Грэм, "Почему умным людям приходят в голову глупые идеи"
http://www.perevedem.ru/article/why-smart-people-have-bad-ideas.htm

Fitts Law

Егор Шокуров тут подкинул -

Лабораторная работа по закону Фиттса. Закон Фиттса гласит, что "время, требуемое для позиционирования на какой-либо элемент есть функция от расстояния до этого элемента и от его размера"

Советую попробовать это на собственной шкуре собственном опыте - занятное ощущение.

http://fww.few.vu.nl/hci/interactive/fitts

Расстояние до счастья

Расстояние до счастья - это количество шагов от результатов твоей деятельности, на котором люди получают от нее пользу.

Самое короткое расстояние до счастья - у устроителей опен-эйров, врачей, фокусников и сантехников. У службы техподдержки оно колеблется в районе 2-4 шагов (техподдержке сказали что сломался холодильник, человек на стойке принял холодильник, мастер починил, хозяин счастлив)

У программистов расстояние до счастья велико - они пишут программы, которые помогают автоматизировать чужие бизнесы, которые опосредованно приносят щастье их владельцам (и, возможно, клиентам бизнеса)

Как подружить Oracle Geospatial Data и Google Maps

http://www.oraclebi.ru/2007/07/24/google/

Антипаттерн: Менеджер - пересылальщик писем

Менеджер, который не приносит пользы. Такой менеджер думает, что его работа заключается лишь в распределении задач между подчиненными и представителями сторонних групп разработки. Признаки, что на проекте действует такой менеджер, очень простые - как правило, все письма от него это forward писем от других людей с припиской "FYI" или "сделай, пожалуйста".

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

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

История одной "примадонны" на RSDN

Читаю сейчас тред на форуме RSDN (http://www.rsdn.ru/forum/message/2883756.1.aspx) и это какой-то детектив.

Начинается все с классического менеджерского вопроса "что делать с примадонной"

"На проекте присутствует сотрудник с таким
паттерном. Подскажите, что делать?"

...

"Тут какая проблема: из команды разработчиков (три человека) в начале проекта на него приходилось 70-80% работ, сейчас (спустя время) объем работы возлагаемого на него стал примерно 30%-40% (плавное снижение его степени участия в работе над проектом со стороны руководства), сейчас получается что уменьшение степени участия этого сотрудника влияет на сроки сдачи в худшую сторону."

Затем какое-то кол-во постов занимают стандартные советы, поперемешанные с флудом, народ предлагает сделать примадонну лидом, предлагает потихоньку выводить из проекта и все такое.

А вот затем начинается интересности, когда автора поста начинают расспрашивать о подробностях:

0rc>>Он сам просит выделить какой-нибудь проект, где он в чистую
может показать только свою работу. Как быть?

ГВ>Зачем это ему обязательно "показывать только свою работу"? Похоже на
оборонительную позицию. С чего бы это?Потому что паттерн "примадонна" применен исключительно к талантам + он не может работать со многими.

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

Пока выглядит как обычный конфликт, типа "толковый спец, который начинал проект, но не может работать в команде" + некоторое непонимание менеджером сути конфликта в подотчетной команде - больно уж странным выглядит его объяснение.

Смотрим дальше... А дальше автора поста спрашивают, а почему бы не отдать проект одному этому человеку, раз он суперэффективен. А вот почему:

0rc> Начальство решило, не спрашивайте почему, просто решило и ему
веднее, что лучшим мерилом денег будет — строчки кода. Но он пишет слишком компактный код, из-за этого все проблемы.

http://www.rsdn.ru/forum/message/2886396.1.aspx

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

Я всегда считал, что человек - такое существо, которое может само себя загнать в мир полного абсурда, и даже этого не заметить.

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

Я буду эту историю долго помнить. Надеюсь, я ее вообще никогда не забуду.

TFS при разработке Rosario

А мы все не спим.. :)

На channel 9 интересное видео про то, как команда MS Visual Studio использует Team Foundation Server при разработке следующей версии VS codename Rosario

http://channel9.msdn.com/ShowPost.aspx?PostID=391362#391362

Антипаттерны Test Driven Development

Сергей Розовик перевел интересную статью TDD Antipatterns. Крайне советую прочитать всем, кто как-то связан с созданием юнит-тестов.

"Лжец (The Liar). Тест, который успешно проходит во всех случаях. Однако при ближайшем рассмотрении оказывается, что фактически ничего не тестирует

.Попробуй запусти! (Excessive Setup). Тест, который требует сложной и длительной настройки тестового окружения перед запуском. Иногда тест содержит сотни строк кода, подготавливающие необходимые условия для запуска одного теста. В результате очень сложно разобраться действительно тест не прошел, либо что-то случилось с настройками...."

http://stump-workshop.blogspot.com/2008/01/tdd-anti-patterns.html