Category: литература

Category was added automatically. Read all entries about "литература".

cartoon

Пинок под зад

В конце 90-х и начале 2000-х, когда мы с коллегами-программистами начинали всерьез интересоваться проблемами организации разработки ПО, годной литературы на русском языке было очень мало, а интернет в России еще под стол пешком ходил. Но это не означает, что не было книг о Методологиях. И вера в силу методологий и процессов была невероятно высока.

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

Но понимали ли мы, почему надо делать так, как пишут в "учебниках"? Почему оно работает, когда работает, и наоборот?

Ну разумеется нет, откуда? Для этого требуется кое-что большее, чем ум, и свежая голова.
Collapse )

cartoon

Миф о документации

Программист, заступая на новую работу, каждый раз искренне изумляется и негодует, что "система не документирована". Это негодование - по соей силе бледное подобие негодования второго рода, которое тот же программист испытывает, если ему предложить описать простым человеческим языком, что он недавно наколбасил. И не забывать регулярно обновлять каждый раз, когда он вносит в колбасево изменения.

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

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

А у нас применяется JavaDoc/Oxygen/ПрочаяХуйня, скажете вы. А я всегда аккуратно пишу эти гребанные комментарии, языком Пушкина и Толстого, скажете вы.

А я вам, во-первых - на предмет "аккуратно" и "всегда" не поверю. :) Ну, в самом деле, говорить всякое можно, но меру-то знать надо. :)

А во-вторых - в описываемом мной явлении дело вовсе не в JavaDoc. И не в том, что надо, наступив себе на яйца, непрерывно "документировать".

Дело в другом. Если вы все понимаете, то реальность - она такая, какая есть. Что характерно - если вы не все понимаете - то она один хер такая, как есть. Она состоит в том, что "документация" - это неуловимый Джо, и на это есть вполне объективные причины. Если, конечно, речь не идет о публичном API систем, которым активно пользуются, ну, хотя-бы, десятки тысяч людей (и тогда аудитория "читателей" сравнима с тиражом книги).
cartoon

Комплимент

"Сборник Виктора Пелевина «Ананасная вода для прекрасной дамы» оказался сборником утешений для тех, кто уже не в состоянии верить своим глазам.

Виктор Пелевин, по сути, это Джулиан Ассанж пространства духовности – организует утечки, срывает маски, раскрывает тайную переписку высших и низших разумов, скрывается неизвестно где."
Читать полностью: http://gazeta.ru/culture/2010/12/08/a_3459985.shtml

Знаете, что примечательно в этой цитате? Не то, что Пелевина сравнили с Ассанжем. А то, что автор этого сравнения как-бы польстил этим сравнением Пелевину. Сделав ему комплимент.

Быстро и незаметно - что-то изменилось в массовом сознании. Настолько быстро, что мы не успели это пока заметить. Но - уже изменилось. И продолжает меняться. Не пропустите момент - смотрите внимательно.
cartoon

Планирование и инженерия

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

Такое бывает не всегда, не все инженеры такие, но это распространенный паттерн поведения.

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

Такое бывает не всегда, не все менеджеры такие, но это распространенный паттерн поведения.

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

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

Самое удивительное в этой ситуации - знаете что? То, про что Том ДеМарко предпочитает не упоминать. Менеджеры (как бы кто ни думал) не размножаются почкованием. Часто они получаются из самых настоящих инженеров. И - при этом все равно воспроизводят тот же самый паттерн поведения.

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

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

И тут дело не только и не столько в квалификации. Вся хохма в том, что сами инженеры не так глубоко разбираются в проблемах соседних инженеров. :) Так же часто, как они считают менеджеров идиотами, они склонны считать проблемы соседних инженеров простыми. А свои собственные - сложными. Задача, над которой работает сосед - проста, и только своя собственная - "по настоящему серьезна". (1)

Сами понимаете, такое бывает не всегда, не все инженеры такие, но это распространенный паттерн поведения.

Дело в том, что только углубившись в технические проблемы (и потратив дохрена времени), можно понять, где лежат "грабли" (1а).

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

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

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

Этот один вовсе не обязательно должен быть идиотом. Пусть он - наиболе еталантливый инженер. Но и не будучи идиотом, он все равно подвержен интуитивному фактору (1). Возможности человеческого мозга ограничены, и поэтому он не может понять все. Знать и понимать все в принципе невозможно. См (1а).

И в этой ситуации - у некоторых инженеров уже возникает повод таки считать его идиотом.

И тут уместно сказать, что подозрения менеджеров также не беспочвенны. Инженеры часто ведут себя как избалованные дети. Вынуждая менеджеров относится к себе, как к избалованным (и умственно отсталым, ибо не понимают объяснений) детям. Том ДеМарко очень много говорит о том, как надо себя вести менеджерам (которые часто вчерашние инженеры), но ничего не говорит про то, что инженеры частенько ведут себя именно как дети. Как еще к ним относиться, блин?

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

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

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

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

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

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

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

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

Решение? Оно есть. Auftragstaktik. Философия и практика руководства, предлагающая как руководителям, так и починенным измениться, и выйти из описанного порочного круга.

Про Auftragstaktik и "декларативное планирование" ищите по тегам. Я устал писать пост - если соберусь писать книгу (вряд-ли, но не исключено, что все-таки соберусь), - там все расскажу.
cartoon

Вопросы к интервью

На конференцию software_people приезжают Питер Хрющка (http://softwarepeople.ru/sp2010/participants/speakers/hruschka/ - соавтор последней книги Тома ДеМарко Adrenaline Junkies and Template Zombies), и Дон Сайм (главный разработчик языка F# - http://softwarepeople.ru/sp2010/participants/speakers/syme/).

И у обоих я буду брать интервью. Интервью с Доном Саймом я буду брать вместе с известным экспертом в области функционального программирования и адвокатом Хаскеля Сергеем Зефировым (thesz), который пока об этом не знает, но, я уверен, согласится. Ведь тема, сами понимаете, провокационная. В F# нет монад, и это строгий язык. Но, там есть "_как-бы_ монады". Будет интересно.

Ну, а с Питером Хрущкой мы поговорим о человеческом факторе.

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

ЗЫ: В конце software people будет пивная вечеринка. Будет темный Guinness, нефильтрованный Edelweiss, и безалкогольный Buckler. Имейте в виду! Пруфлинк - смотрите на логотипы внизу страницы: http://softwarepeople.ru/sp2010/

P.P.S: Да. Еще я взял интервью у Уокера Ройса, директора Rational Software, на тему ретроспективы и перспективы процессов разработки. Уокер жжот. Оно ждет одобрения в IBM, и после этого я его опубликую.
cartoon

Software People: вторая презентация

Так получилось, что во второй день конференции один из докладчиков не смог прийти, и меня попросили его заменить.

Забавно, собственно, что. В первый день, когда я выступал с докладом про принципы разработки структуры плана, меня спросили - а что же насчет планирования сроков? Я ответил - "это тема другого моего доклада". Я на самом деле год назад делал доклад ровно на эту тему на другом мероприятии. Аудитории такой ответ понравился :).

И вечером, после выступления, организаторы мне сообщили, что от меня требуется доклад на замену. :) Забавно. Таким образом, во второй день я прочитал доклад о прогнозе сроков.

В принципе, в паре они _почти_ закрывают тему планирования. "Почти" - потому, что технику прогнозирования сроков я разработал независимо от декларативного "планирования", и задача их совмещения не так проста. Хотя...

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

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

Вторая техника - вот как ее срастить с "декларативным планированием" - честно говоря пока не думал. Ибо вопрос корелляций времени и объема на самом деле весьма не простой и далеко не очевидный. К примеру, PSP/TSP - методология, целиком построенная на метриках, статистике, и корелляциях, невероятно сложна. Ее просто невозможно внедрить самостоятельно не то что после 40-минутного доклада, но и после прочтения и понимания книги.

Техника 2 из второго доклада может быть, в отличии от PSP/TSP внедрена немедленно после доклада, и дает весьма неплохой эффект (value/cost существенно превышает PSP/TSP), но с первым докладом пока не стыкуется.

Итак, вот презентация.
http://www.slideshare.net/gaperton/ss-1479468

А вот и предыдущая - "декларативное планирование".
http://www.slideshare.net/gaperton/auftragsplanning-pre-final-1479467
cartoon

Об умении читать текст

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

Один из участников дискуссии на RSDN дал ссылку на фундаментальный труд по данной проблеме:

КАК НАМ ВСЕМ НАУЧИТЬСЯ ЧИТАТЬ, ЧТО НАПИСАНО?
Небольшой мануал с веселыми заданиями, красочными примерами и психологическими тестами
http://linorg.ru/how-to-read.html

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

Вот пост:
>> к пункту *помогать подчиненным, если не получается* прилагается еще
>> пункт /следить чтоб не косячили/
V>А вы попытайтесь не следить, это же ваши подчиненные и вы их брали,
V>эффективность труда их повысится.
V>Если же вы им не доверяете, какой смысл их держать и следить за ними?
V>Да и в таком случае проще делать все самому, но все сам не сделаешь.

А вот мой ответ.


Должно хватить базового умения читать отдельные слова, ИМХО. :)

ЗЫ: Короче, текст прочитать - это вам не хухры-мухры! А недокументированный текст - это просто несерьезно. Что за манеру взяли авторы писать тексты без комментариев и картинок? Это оправдание лени. А что говорят, что текст прочитать надо, чтобы понять о чем он - дык так тока лохи делают. Ваще, непонятно зачем оно нужно - читать, когда буков много. И без этого можно отвечать, и ничего!

cartoon

Disclaimer

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

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

Сюжет выдуман. Хотя некоторые его мелкие элементы и основаны на реальных событиях, в целом сюжет - плод фантазии автора. Хотя у некоторых персонажей истории и есть реальные прототипы (куда ж без этого), манеры поведения прототипов в реальной жизни и характеры, в целом, весьма далеки от таковых у персонажей истории. В целом, в данных историях примерно процентов 80% вымысла, и процентов 20 фактов. Данная пропорция будет сохраняться, я думаю.

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

Нет, но почему все-таки фамилии «похожи», ведь кто-то может про кого-то что-то нехорошее подумать? Знаете-ли что, всегда найдется тот, кто про своего ближнего нехорошо подумает, только повод дай. Это определяется исключительно мерой испорченности читателя.

"Мучительно искал, где улыбаться. Не нашел.."

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

"...в принципе, и литературная сторона там, мягко говоря, средненькая..."

Помилуйте, сами же знаете, что такое у нас блоги, а что - Литература. Литературная сторона - это у нас Толстой, Достоевский, знаток русской жизни и языка Максим Горький и еще этот, как его, Коэльо, прости господи, с Кафкой. :) А здесь - блог. :)
cartoon

Моделирование динамики процесса разработки ПО

Стало ужасно модной темой последнее время.

из наших этой темой плотно занимается Байрам.
http://edu.it-online.ru/education/guru-academy/annakov_dyn/

да что Байрам, сам Йордан будет в сентябре с семинарами на эту тему в России,

http://edu.it-online.ru/education/guru-academy/yourdon_peopleware_wargames/index2.shtml

Ну и сам Том ДеМарко пишет об этом в своем "Deadline". Это совершенно замечательная книга, роман об управлении проектами, представитель редкого сейчас жанра "производственный раман". Вот помните хардкорные советские производственные фильмы? Вот это примерно то же самое :). И в одной из глав данной книги автор рассказывает про динамические модели Абдул-Гамида.

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

Collapse )
cartoon

Как составлять планы, или "декларативное планирование" :)

Feeling comfortable with declarative programming? :) Now it's time for declarative planning!

НЕДОПИСАНО. To be done.

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

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

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

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

Collapse )