Семен ([info]sim0nsays) wrote,
@ 2007-09-08 18:12:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:tech

Коллективный разум: How to
Я нашел в MS дядьку, с которого дико тащусь.

Его зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OGL в SGI, писал по нему книжку, а сейчас вот архитектит в том числе D3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 20 и просветлился больше, чем за два предыдущих месяца. Читал его гуидлайны про API design и опять же радовался.

Отрывок на сегодня:

"DESIGN BY COMMITTEE. Avoid design by committee. There should be a single person with final say in the design .... and this person should have good architectural experience and instincts."

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



Вот мне очень нравится Design Review и я всем его советую. Это когда перед тем как кодать что-то, надо об этом рассказать команде или еще кому, у кого есть время и понимание происходящего. Тебе обязательно наговорят кучу фидбека, вспомнят 10 тонких мест, о которых ты не подумал и предложат альтернатив. И часто окажется, что первая идея дизайна не идеальна, а может и вторая. Или неплоха, но нужно додумывать.

Если их фичи на тебя завязаны, то еще и посмотрят и прикинут как вы будете интегрироваться. Так как Design Review взаимный, то и ты будешь знать о той стороне. Кроме того, и знания людей о проекте расширяются и начинают больше пересекаться, и код твой понимать проще, и Code Review становится гораздо более осмысленным занятием.

Хорошо бы после этого обсуждения еще и записать основные принятые решения и почему. Конечно, с какой вам лично хочется детальностью, от детального Design Spec до коротенькой странички "overview and key decisions".

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

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

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

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



Design Review - это очень хорошая и правильная вещь. Принцип Avoid Design by Committee ее дополняет, а никак не перечеркивает. Отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу. То есть - коллективный разум таки действительно рулит. Решение, которое ты примешь не рассказав и не посоветовавшись - будет хуже. Но тем не менее, принимать решение - только тебе самому.

А у Дэвида это все - одной строчкой. Эх...

Crossposted to blog.gamedeff.com




(Post a new comment)


[info]fandir
2007-09-09 02:10 am UTC (link)
Да, оно хорошо, когда есть. У нас - есть. Может быть, плохо, что я еще не работал там, где этого нет?

(Reply to this)


[info]watkin
2007-09-09 06:05 am UTC (link)
Ну, обычно, кто делает таск, тот и принимает решение, на которое может повлиять "главный программист". А вот Code Review, это да. Есть желание сделать втихую и показать готовое, с таким желанием надо бороться :), поскольку часто приходится переделывать/доделывать.

(Reply to this) (Thread)


[info]sim0nsays
2007-09-09 06:56 am UTC (link)
Да, всяко, решение должен принимать тот, кому это все писать.

(Reply to this) (Parent)


[info]alexeychen
2007-09-09 09:11 am UTC (link)
И он тоже в M$ =(

(Reply to this)

you in a army...
[info]kkray
2007-09-09 02:08 pm UTC (link)
А был/будет пост про проджект мэнэджмент в M$ ? Или я пропустил?
Уж очень интересно, как M$ умудряется управлять такой армией.

(Reply to this) (Thread)

Re: you in a army...
[info]fandir
2007-09-09 04:48 pm UTC (link)
Тут, правда, не проджект, а програм менеджмент, но все же.. http://www.gotdotnet.ru/Channel9/360386.aspx

(Reply to this) (Parent)

Re: you in a army...
[info]sim0nsays
2007-09-09 05:51 pm UTC (link)
Это слишком суровая тема. Вот переживу релиз Виндовс, тогда может быть...

(Reply to this) (Parent)

Re: you in a army...
[info]gaus
2007-09-12 06:30 pm UTC (link)
почитайте блог mini msft. Там очень много на эту тему, особенно в комментариях

(Reply to this) (Parent)(Thread)

Re: you in a army...
[info]sim0nsays
2007-09-12 08:45 pm UTC (link)
И, конечно, все является абсолютно полным описанием!

(Reply to this) (Parent)(Thread)

Re: you in a army...
[info]gaus
2007-09-13 04:24 am UTC (link)
Ну, любая информация неполна. Полная информация возможна, однако она может быть доставлена за бесконечное время. Cигнал/шум, теорема Шеннона, всё такое :)

P.S. Я вот почитал книжку Скотта Беркуна (9 year msft veteran), он пишет в частности. что одна из функций менеджера - защищать своих программистов от процесса.

(Reply to this) (Parent)(Thread)

Re: you in a army...
[info]sim0nsays
2007-09-13 05:15 am UTC (link)
Хорошо, скажу грубее. Попробуйте на minimsft научиться делать компанию, которая приносит 40 bil/year дохода и 15bil/year прибыли.

(Reply to this) (Parent)(Thread)

Re: you in a army...
[info]gaus
2007-09-13 06:35 am UTC (link)
Ты чего злой такой? :)

На minimsft инсайдеры MS описывают разное из проджект менеджмента. А вот какую роль в финансовом успехе MS играет собственно менеджмент программных проектов, а какую - маркетинг, гениальная интуиция BG, подковерные игры с правительствами и контракт с дьяволом - вопрос отдельный :)

(Reply to this) (Parent)(Thread)

Re: you in a army...
[info]sim0nsays
2007-09-13 06:46 am UTC (link)
Ну, они однобоко его описывают, я только про это. Т.е. дохрена чего плохо, но как бы Винды делать получается. Совсем нетривиальное занятие, совсем.

(Reply to this) (Parent)


[info]darypola
2007-09-09 07:20 pm UTC (link)
Как хорошо, наверное, с такими guidelines. Завидую. :)
А я и мой проект - постоянные жертвы коллективного дизайна. Сезонные помощники на проекте артачатся, отказываются менять дизайн своей части, чтобы он совпадал с общими принципами, принятыми в проекте, мотивируя тем, что "все и так работает" и вообще они с общим дизайном не согласны. Менеджмент полномочиями "последнего слова" кого-либо наделить не хочет, не смотря ни на что. Так и мучаюсь, - приходится упрашивать, брать измором, либо переписывать все потом самой.

(Reply to this) (Thread)


[info]sim0nsays
2007-09-09 07:24 pm UTC (link)
Ну, за свою часть действительно каждый решает сам. Но в общий дизайн системы - тоже должен быть решен одним человеком. По хорошему - тем, кто больше всего похож на "архитекта".
Умение работать вместе и уважать чужие решения - вообще тяжелая штука.

(Reply to this) (Parent)


[info]drcb
2007-09-09 07:53 pm UTC (link)
> А у Дэвида это все - одной строчкой. Эх...

Так он наверно не в первый раз это говорит. Наверно даже не в сотый :)
Отточил уже!

(Reply to this)


[info]darypola
2007-09-09 08:00 pm UTC (link)
Интерфейс любой части, вобщем-то, уже часть общего дизайна. И если человек спроектировал его не таким, какой уже у пяти существующих частей, просто потому что поленился уточнить, посмотреть как они сделаны, но не поленился полдня об этом спорить, то тут уважение к чужому решению не может помочь. Не менять же дизайн всех остальных пяти частей или превращать проект в коллективную свалку, потому что кто-то не хочет разобраться с существующим дизайном. ;)

(Reply to this) (Thread)


[info]sim0nsays
2007-09-09 08:13 pm UTC (link)
Ну, если ему высказали весь этот фидбек и рассказали, почему и как спроектированы текущие, а он все равно упирается - это уже карма.
Чаще, по-моему, это происходит не поэтому, а потому что design review нет как такового. То есть человек решает сам и делает сам, ни у кого ничего не спрашивая. А только потом ему уже начинают говорить, когда он решение уже сам принял.

Это и есть плохая культура программирования без понимания важности Design Review, которую я видел везде в Росии.
Человек сам должен понимать, что сначала надо поговорить со всеми и понять, что они думают.

(Reply to this) (Parent)(Thread)


[info]darypola
2007-09-11 07:16 am UTC (link)
Да согласна. Не знаю почему у нас так мало людей считают культуру программирования чем-то значащим. Может из-за ориентированности только на такие ценности как должности и зарплаты.

(Reply to this) (Parent)


[info]printsdatskiy
2007-09-10 06:43 am UTC (link)
Интересно только, что делать, если автор Design Spec не желает видеть недостатков своего дизайна?

(Reply to this) (Thread)


[info]sim0nsays
2007-09-10 05:10 pm UTC (link)
Его решение. Естественный отбор.

(Reply to this) (Parent)


[info]vladonsays
2007-09-17 04:06 am UTC (link)
Блин, круто написал. Мы недели 2 назад как раз практиковали такой подход. Сначали обсуждали дизайн и реализацию, затем взвесили все за и против и у нас получилось конечное решение, удовлетворяющее всех участников проекта :)
Тока я тогда интуитивно решил так действовать, потому как посчитал, что скорее всего есть решение красивее и если мы вместе обсудим таск, то оно и родится :)
В общем cool, теперь буду знать, что данный подход даже описан в книге.

(Reply to this) (Thread)


[info]sim0nsays
2007-09-17 06:59 am UTC (link)
Мммм. Ну, тут типа не совсем так. Типа, надо каждое решение обязательно обсуждать и дизайн и реализацию в любом случае, а если до удовлетворяющих всех дойти не получается, то должен быть один принимающий решение.

(Reply to this) (Parent)(Thread)


[info]vladonsays
2007-09-17 11:04 am UTC (link)
это я понял, в нашем случае так и было, обсуждали и то и то, просто мы смогли найти удовлетворяющее всех решение :)

(Reply to this) (Parent)

(Reply from suspended user)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…