Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2017

Даёшь дешёвую безопасность!

David Platt в своей колонке в журнале MSDN затронул замечательную тему - цену безопасности в ИТ. Более детально этот предмет изучен Cormac Herley В человеческом обществе понятие цены имеет оттенок наживы, поэтому многие отказываются и даже считают зазорным применять это понятие ко многим аспектам жизни человека и общества, например любовь, дружба, свобода, справедливость, здоровье, и т.п. Не побоюсь показаться прагматиком или даже циником, но моё мнение - всё имеет цену, вопрос только в том чтобы правильно рассчитать формулу и подобрать верные единицы измерения цены (хотя американский доллар работает удивительно хорошо в удивительно многих случаях, он действительно не покрывает 100%). Возвращаясь к вопросу ИТ безопасности, то даже если отбросить количество долларов выплачиваемых за всевозможные антивирусы, фаерволы, бекапы и т.п., то это далеко не покажет нам картину реальной цены, выплачиваемой ИТ пользователями за их безопасность. Реальную картину очень хорошо можно продемонстрировать по аналогии с занятиями спортом. Все мы прекрасно знаем, что если регулярно ходить в спортзал, то тело будет в хорошей форме и здоровье будет богатырское. Какова цена такого замечательного дела? Цена членства в ближайшем спортивном клубе? Думаю многие убедились на своём опыте, что это полнейшая иллюзия, что реальная цена - это многие часы вашего времени, и затраченные усилия на то, чтобы действительно посещать этот клуб. Думаю многие также убедились, что эта "скрытая" цена на самом деле на порядок выше стоимости членства в клубе, и что она на самом деле настолько высока, что многие через какое-то время отказываются её платить и бросают клуб даже ценой потери уже проплаченного годового абонемента. Что же безопасность? Зачастую та же проблема - мы все знаем что мы должны делать чтобы быть в большей безопасности; пароли должны быть сложнее, менять их надо чаще, они должны быть разные для разных сервисов, должен быть установлен фаервол, антивирус, бекап, и т.д. и т.п. Однако большинство людей, зная всё это, сознательно этого не делают. Специалисты по ИТ безопасности разводят руками, качают головами и не могут понять беспечности и недисциплинированности пользователей. А пытался ли кто-то подсчитать реальную цену безопасности? Не в долларах потраченных на софт, а в реальных затратах времени, усилий и внимания пользователей на соблюдение всех этих процедур? Что если несоблюдение рекомендаций не есть беспечность или недисциплинированность, что если это осознанный выбор, и безопасность не нужна большинству пользователей по такой высокой цене? Представим некий взлом, который затрагивает 1% пользователей ежегодно, и требует 10 часов их времени для восстановления системы. Любой совет по предотвращению такого рода взломов, требующий от пользователей более 1 секунды их времени в день, будет в сумме большим вредом для пользователей, чем сам взлом. Неудивительно что пользователи быстро это осознают и начнут игнорировать этот совет, как имеющий неоправданно высокую цену для них. Подобного рода закономерности наблюдаются даже в корпоративном мире, где ИТ-отдел навязывает сотрудникам "дорогие" правила, от которых они не могут отказаться. Дэвид предлагает забавный мысленный эксперимент: представьте хозяин вашей съёмной квартиры поставил кодовый замок на дверях туалета. Вы наберёте код раз, может два, но потом вы точно что-то придумаете: будете оставлять дверь открытой чтоб она не захлопывалась, или обмотаете замок скотчем, или начнёте справлять нужду в раковину на кухне. Поэтому авторы статей типа "101 способ предотвратить взлом почты" должны подумать дважды о том, сколько пользователей согласиться читать, помнить, и выполнять их 101 рекомендацию. В США около 180 миллионов взрослых пользователей. время которых в среднем стоит $14 в час, то есть один час времени американских пользователей стоит два с половиной миллиарда долларов! Основная причина по которой советы по поддержанию ИТ безопасности так часто просто игнорируются пользователями кроется в этом гигантском заблуждении о бесплатности времени пользователей - ресурсе, цена которого на самом деле 2.5 миллиарда баксов в час. Очень популярно считать пользователей ленивыми, безответственными, невнимательными и тяжёлыми на подъём, но вы подумайте о них как о специалисте, цена на услуги которого $2500000000 в час, и вы не захотите больше отнимать ни секунды его времени.

Categories: Books & Articles
Posted by Vitalii Tsybulnyk on Saturday, September 15, 2012 5:45 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Ау, остался кто-нибудь белый и пушистый?..

Этот пост будет коротким и по существу, только факты: Разработчик Тревор Экхарт (Trevor Eckhart) несколько дней назад нашел в прошивке смартфона под управлением Google Android программное обеспечение IQRD от компании Carrier IQ. Экхарт обнаружил, что IQRD тайно регистрирует каждое нажатие кнопок, даже тех, которые отображаются на сенсорной клавиатуре мобильного гаджета. Экхарт представил видео-доказательство, демонстрирующее как IQRD тайно сохраняет текстовые сообщения и поисковые запросы. Руткит фактически получил доступ к зашифрованной информации, передающейся через HTTPS-соединение. При включении устройства IQRD запускается автоматически и попытки его принудительно отключить ни к чему не привели. К сожалению, на данный момент не совсем понятно, какая именно информация передается и как она используется, хотя сам факт присутствия такого программного обеспечения уже вызвал множество вопросов. Ещё весной хакер Грант Пол нашёл аналогичный софт CIQ на iOS. Apple обещает перестать поддерживать Carrier IQ с релизом iOS 5, но Carrier IQ вё ещё работает на iOS-устройствах с пятой прошивкой. Apple утоверждает что данные диагностики отправляются к ним только когда клиент согласен делиться этой информацией.  Дальнейшие исследования показали, что такая же проблема затрагивает и телефоны Blackberry. Единственная из популярных мобильных систем, где CIQ пока не нашли — это Windows Phone 7.   Источники: 1. androidmarket.ru: Руткит на Android 2. iphones.ru: Шпионская Carrier IQ найдена в iOS

Posted by Vitalii Tsybulnyk on Monday, December 5, 2011 6:45 AM
Permalink | Comments (5) | Post RSSRSS comment feed

Как я познакомился с Рихтером

Я думаю, что большинству читателей этого блога излишне отдельно представлять Джеффри Рихтера (Jeffrey Richter). Ворвавшись в мир разработки под Windows в конце девяностых, к началу 2000-х он стал настоящей иконой, а его книга о программировании под .Net Framework и по сей день остаётся библией для всех C#/.Net разработчиков. Отлично помню как в году 2005-м слово "рихтер" уже было нарицательным, а "знакомство с рихтером" было необходимым условием прохождения собеседований и трудоустройства в качестве .Net разработчика. Наконец-то я выполнил это условие :-)   Начну с того, что моя компания постоянно проводит всевозможные тренинги, давая сотрудникам возможность расти и развиваться в том числе и таким способом. Обычно я смотрю на эти вещи "сквозь пальцы", однако наткнувшись на имя Рихтера не смог удержаться и записался на двухдневный курс многопоточного программирования. Хотя я и не рассчитывал услышать ничего для себя принципиально нового в этой области, курс превзошёл все мои ожидания. Я узнал такие тонкости взаимодействия между CPU, Windows и CLR для создания и управления потоками, о которых я даже не догадывался. Рихтер не отпускал внимание аудитории ни на минуту, и после первого дня тренинга я пришёл домой и тут же заснул, возможно в том числе и от количества полученной информации. По окончанию тренинга на второй день я подошёл к Джеффри, представился и поблагодарил за замечательный курс. Джеффри было заметно приятно слышать это, он поблагодарил меня в ответ, пожал мою руку, и у нас завязалась беседа, о том как уже почти 10 лет назад я начинал с его книг, и у меня и по сей день хранится экземпляр его книги на русском языке (кстати, это единственная техническая книга на русском, которую я до сих пор храню - уж очень она дорога моему сердцу). Джеффри рассказал мне пару историй о том, как ему всегда интересно видеть свои книги на незнакомых ему языках, иногда бывают забавные сюрпризы, например немецкий перевод книги в несколько раз тоще оригинала :-) По счастливой случайности, мой русский перевод книги оказался у меня с собой ;-), что сделало меня гордым обладателем экземпляра знаменитой книги с личным автографом автора:   В заключение отмечу, что я сделал пару полезных для себя выводов: Независимо от того, как много сделал человек, ему всегда приятно и важно узнавать о том, что его работа ценна и востребованна для множетсва других людей, особенно если этот человек не популярный актёр, а интеллектуал и технический (не побоюсь этого слова) гений Наверное я всё ещё не привык окончательно к тому, где и над чем я сейчас работаю, с какими людьми встречаюсь, и какие уникальные возможности это даёт чтобы расти профессионально и открывать для себя новые и новые горизнонты. Только сейчас я начинаю в полной мере осознавать и ценить всё это.

Posted by Vitalii Tsybulnyk on Wednesday, September 28, 2011 7:41 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Интервью газете Данкор

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

Posted by Vitalii Tsybulnyk on Friday, June 3, 2011 6:58 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Как зародилась идея iPad или "It Took Over 20 Years to Ship"


Categories: Books & Articles
Posted by Vitalii Tsybulnyk on Thursday, January 27, 2011 1:36 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Архитектура программного обеспечения с человеческим лицом

С задержкой в несколько месяцев наконец-то вышел №2 журнала RSDN за 2010-й год с моей статьёй "Архитектура программного обеспечения с человеческим лицом". Первая версия статьи была написана ровно год назад, в декабре 2009-го, и стала своеобразным итогом моего видения процесса разработки программного обеспечения в целом, и его архитектуры в частности, как гибкого, человеко-центристского, я бы даже сказал социального явления. Статья несколько раз дорабатывалась и даже переписывалась вплоть до весны 2010, когда и созрел окончательный вариант, отправленный в RSDN. Электронная версия статьи ещё не появилась на rsdn.ru, и мне не известны сроки её электронной публикации. К сожалению, RSDN не продаётся и не доставляется вне Росиийской Федерации, так что если вдруг у кого-то уже имеется бумажная копия журнала, или есть намерение приобрести, я был бы крайне признателен за сканы. Традиционная аннотация: В статье автор подводит итог и пропускает через призму собственного опыта основные человеческие аспекты архитектуры программного обеспечения. Рассматривается эволюционная природа архитектуры, особенно ярко выраженная в малых проектах и стартапах. Субъективность решений по поводу применения шаблонов проектирования в социальном контексте конкретного проекта приводит к наличию разных стилей применения этих шаблонов. Неоднозначность и многогранность роли архитектора подчёркивает и усиливает первоочерёдность человеческих факторов (личных и командных) для процесса принятия технических решений и проектирования архитектуры в проектах по разработке программного обеспечения.

Posted by Vitalii Tsybulnyk on Sunday, December 5, 2010 2:15 PM
Permalink | Comments (3) | Post RSSRSS comment feed

Контроль or not контроль?

Том ДеМарко не нуждается в отдельном представлении, на его книгах выросло не одно поколение руководителей и разработчиков, вот лишь некоторые их этих книг: 1986. Controlling Software Projects: Management, Measurement, and Estimates. Prentice Hall 1987. Peopleware: Productive Projects and Teams. With Timothy Lister. Dorset House. 1997. The Deadline: A Novel About Project Management. Dorset House. 2003. Waltzing with Bears: Managing Risk on Software Projects. With Tim Lister. Dorset House in March, 2003. Контроль над протеканием проектов разработки ПО - одна из ключевых тем его работ. Именно ему принадлежит ставшая крылатой фраза "You can’t control what you can’t measure" ("Вы не можете контролировать то, что невозможно измерить"). Однако сегодня лично мне очень приятно наблюдать, как этот действительно умный и талантливый человек меняет свою точку зрения на аспекты контроля вместе с изменением видения всего процесса в ИТ индустрии. Этот человек не боится признать, что был не прав, и статья [1] полностью посвящена такому признанию. Вот что он пишет: Моя ранняя книга по метрикам 'Controlling Software Projects: Management, Measurement, and Estimation' (Prentice Hall/Yourdon Press, 1982) сыграла важную роль в том, как многие инженеры-разработчики измеряли свою работу и планировали проекты. Под настроением провести некоторую рефлексию я спрашиваю себя: были бы мои советы в силе и сейчас, спустя столько времени? Верю ли я сам всё ещё, что метрики являются обязательным аспектом успешного процесса разработки ПО? Мой ответ: нет, нет и нет. По собственному признанию, Том не учитывал в своих работах о метриках многих важных и очевидных сегодня вещей: - не все метрики одинаково хороши и нужны- сбор качественных метрик стоит дорого (время, ресурсы)- метрики должны использоваться осторожно- разработка ПО отличается от естественных наук и её метрики намного менее точны в их попытке измерить те вещи, которые они должны отражать. Основной мыслью работ ДеМарко о метриках всегда было то, что контроль является пожалуй самым важным аспектом любого проекта по разработке ПО. Однако он сам признаёт сейчас, что это не так. Для понимания настоящей роли контроля, нужно различать два совершенно разных типа проектов:  - проект А при вложениях X приносит выгоду/прибыль 1.1*X- проект Б при вложениях X приносит выгоду/прибыль 50*X Очевидно, что контроль очень важен для проекта А и практически совершенно не важен для проекта Б. Это приводит нас к странному выводу, что строгий контроль очень важен для сравнительно бесполезных проектов и менее важен для полезных. Чем больше вы сосредотачиваетесь на контроле, тем более вероятно, что вы работаете над проектом, результирующая ценность которого сравнительно мала. Значит ли это, что можно успешно запускать проекты без особенного контроля? Вот что пишет ДеМарко:  Практически, да. Сначала выберите проект, в котором точный контроль не был бы так важен. Затем снизьте свои ожидания о том, как сильно вы сможете его контролировать. Как же управлять проектом без контроля? Руководите людьми и контролируйте время и деньги. Например, вы можете сказать своим тим-лидам: “У меня есть на уме дата окончания, но я даже не собираюсь вам её сообщать. Когда однажды я прийду и скажу, что проект заканчивается через неделю, вы должны быть готовы всё собрать и выпустить то, что у вас будет на тот момент как финальный продукт. Ваша задача - работать над проектом инкрементно, добавляя кусочки к целому в порядке их важности, и выполняя интерграцию, документирование и приёмочное тестирование такими же этапами.” Это может выглядеть как рецепт гибких методологий, но я ... просто проедлагаю это как подход к управлению. Я постепенно прихожу к выводу что software engineering - это идея, время которой пришло и ушло... Этот термин делает акцент на определённом наборе дисциплин, включая предопределённый процесс, проверки и разборы результатов, разработка требований, матрицы traceability, метрики, детальный контроль качества, строгое планирование с последующим слежением, стандарты кодирования и документирования. Всё это в целях последовательости в практиках и предсказуемости. Последовательность и предсказуемость всё ещё желательны, но они никогда не были наиболее важными вещами. Например, последние 40 лет мы мучались своей неспособностью заканчивать софтверные проекты в срок и в рамках бюджета. Но, как уже намекалось выше, это никогда не должно было быть высшей целью. Более важной целью является трансформация: создание ПО, способного изменить этот мир, или компанию, или то, как она ведёт свой бизнес. Лучше бы мы старались преуспеть в этой трансформации, пусть даже действуя вне рамок нашего контроля. Разработка софта всегда была и остаётся в чём-то экспериментальной. Само создание ПО не обязательно экспериментально, но его концепция - да. И это то, где дожен быть наш фокус. Это то, где наш фокус должен был быть всегда.    Источники 1. Tom DeMarco Software Engineering: An Idea Whose Time Has Come and Gone?

Posted by Vitalii Tsybulnyk on Friday, November 26, 2010 6:49 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Software Architects Are Number One

In their November issue, CNN Money Magazine rated "Software Architect" as the number 1 job in America! What they do: Like architects who design buildings, they create the blueprints for software engineers to follow -- and pitch in with programming too. Plus, architects are often called on to work with customers and product managers, and they serve as a link between a company's tech and business staffs. What's to like: The job is creatively challenging, and engineers with good people skills are liberated from their screens. Salaries are generally higher than for programmers, and a typical day has more variety. "Some days I'll focus on product strategy, and other days I'll be coding down in the guts of the system," says David Chaiken, 46, of Yahoo in Sunnyvale, Calif., whose current projects include helping the web giant customize content for its 600 million users. Even though programming jobs are moving overseas, the face-to-face aspect of this position helps cement local demand. What's not to like: You are often outside the management chain of command, making it hard to get things done. Requirements: Bachelor's degree, and either a master's or considerable work experience to demonstrate your ability to design software and work collaboratively. Stats: Pay: Median pay (experienced) $119,000 Top pay $162,000 Opportunity: 10-year job growth (2008-2018) 34% Total jobs (current) 110,000 Quality of life ratings: Personal satisfaction B Job security B Future growth A Benefit to society C Low stress C Flexibility A

Posted by Vitalii Tsybulnyk on Thursday, October 14, 2010 12:05 PM
Permalink | Comments (0) | Post RSSRSS comment feed

О нобелевских лауреатах и Сколково

Как сам выходец из отечественной науки, я не мог не обратить внимание на обилие в заголовках российских и украинских СМИ тематики о нобелевских лауреатах 2010 года по физике. Ими, как известно, стали двое выходцев из России Константин Новоселов и Андрей Гейм за свои работы по созданию графена. Сам по себе этот факт не вызывает лично у меня абсолютно никакого удивления, особенно с учётом того, что оба учёных уже довольно долгое время живут и работают в Великобритании, где собственно и были выполнены все работы, заслужившие столь высокое признание. Очень удивила появившаяся в ряде российских СМИ  информация о том, что руководитель департамента международного сотрудничества фонда Сколково Алексей Сытников выступил с предложением пригласить нобелевских лауреатов в Россию. По словам чиновника, такая идея в фонде возникла еще  до присуждения Гейму и Новоселову награды Нобелевской премии, так как оба ученых являются яркими представителями науки. Я даже сначала подумал, что чего-то не знаю в этой истории, что ребята, скажем, были выдворены из России по причине их некомпетентности, а теперь заслужили своими трудами уважение чиновников, на основании чего их и соблаговоляют пригласить назад. Но нет, беглое изучение биографий показало, что оба нобелевских лауреата уехали совершенно добровольно, при этом никогда явно не выражая своего желания возвращаться. Это вызвало ещё большее моё удивление от заявлений, преподносящих работу в России (и в частности в Сколково) как нечто, что надо заслужить и чего нужно удостоиться. Недоумение подобная информация вызввла и у самих лауреатов, в частности Андрей Гейм заявил, что он "не знает и знать не хочет" о том, что его собираются пригласить сотрудничать с российским фондом Сколково. "Меня это никак не интересует. У меня нет российского гражданства, я гражданин Голландии, там у вас люди что – с ума сошли совсем?", - заявил Гейм Русской службе новостей. Как рассказал ученый, он не собирается возвращаться в Россию, что ему очень комфортно в Великобритании, что графен мог быть создан и в России, однако "шансы его создания были 1 из 1000 – по сравнению с тем, что можно было сделать за границей". По этой причине физик и принял решение уехать работать за границу. "В Англии я понял, что в течение 6 месяцев там можно сделать то же самое, что в России в 90-х годах сделать в течение 10 или 20 лет. И для экспериментатора, которому нужна аппаратура, средства для исследований, условия работы здесь и там были настолько различные, что даже вопроса не стояло оставаться или нет. Оставаться в России было для меня все равно, что жизнь потратить на борьбу с ветряными мельницами, а работа для меня хобби и тратить свою жизнь на мышиную возню абсолютно не хотелось", - подчеркнул Нобелевский лауреат. Почему же чиновники "от науки" позволяют себе подобного рода заявления, выставляя себя на посмешище и демонстрируя ещё больше ничтожность и жалкое состояние отечественной науки? Неужели они надеются на то, что подчекнув этнические корни учёных они привлекут к себе какое-либо другое внимание, кроме как всеобщее презрение и жалость к государству, которое может сотрясать на весь мир ядерными кулаками, но не способно предложить талантам такого уровня сколько-нибудь приемлемых условий труда и жизни? Или это попытки дешёвой рекламы "супер новационного центра" Сколково, название которого прозвучало в одном заголовке с именами нобелевских лауреатов, пусть даже смысл сводится к "Нобелевские лауреаты ни за что не хотят работать в Сколково"? Как бы там ни было, в этой ситуации порадовала только простая и открытая позиция учёного, не ставшего "заглаживать шероховатости" и выгораживать государство, которое ничего для него не сделало.   Источники 1. korrespondent.net Нобелевский лауреат по физике отказался от предложения работать в Сколково

Categories: Books & Articles
Posted by Vitalii Tsybulnyk on Thursday, October 7, 2010 10:57 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Design Guidelines for Developing Frameworks and Class Libraries

After I spent the last couple of months designing some class library for Windows Azure engineering infrastructure, I realized that design principles for frameworks and class libraries are not exactly the same as for 'off the shelf' or enterprise applications and systems. The fundamental difference is that, in the case of applications, customers don't care about your code at all, so you can use all techniques you want to make your design elegant and easy to maintain. In the case of framework/library, quite the contrary is true: your code is in some ways a user interface, which customers see, use, and care about a lot. Believe it or not, this difference significantly influences your architecture and OOD decisions in ways you may not expect. In this post, I've collected the advice I'd give to framework/library designers. Some of these suggestions are based on these sources [1-2]; however, most of them are from my own experience. Some of this advice might contradict traditional design principles, so be careful and use them for public API/frameworks only. Fundamentals 1. Framework designers often make the mistake of starting with the design of the object model (using various design methodologies) and then write code samples based on the resulting API. The problem is that most design methodologies (including most commonly used object-oriented design methodologies) are optimized for the maintainability of the resulting implementation, not for the usability of the resulting APIs. They are best suited for internal architecture designs—not for designs of the public API layer of a large framework. When designing a framework, you should start with producing a scenario-driven API specification. This specification can be either separate from the functional specification or can be a part of a larger specification document. In the latter case, the API specification should precede the functional one in location and time. The specification should contain a scenario section listing the top 5-10 scenarios for a given technology area and show code samples that implement these scenarios. 2. Common scenario APIs should not use many abstractions but rather should correspond to physical or well-known logical parts of the system. As noted before, standard OO design methodologies are aimed at producing designs that are optimized for maintainability of the code base. This makes sense as the maintenance cost is the largest chunk of the overall cost of developing a software product. One way of improving maintainability is through the use of abstractions. Because of that, modern design methodologies tend to produce a lot of them. The problem is that frameworks with lot of abstractions force users to become experts in the framework architecture before starting to implement even the simplest scenarios. But most developers don’t have the desire or business justification to become experts in all of the APIs such frameworks provide. For simple scenarios, developers demand that APIs be simple enough so that they can be used without having to understand how the entire feature areas fit together. This is something that the standard design methodologies are not optimized for, and never claimed to be optimized for. Naming Guidelines 3. The code samples should be in at least two programming languages. This is very important as sometimes code written using those languages differs significantly. It is also important that these scenarios be written using different coding styles common among users of the particular language (using language specific features). The samples should be written using language-specific casing. For example, VB.NET is case-insensitive, so samples should reflect that. Think about different languages even when you name classes, e.g. don't make mistakes like the NullReferenceException class which can be thrown by VB code, but VB uses Nothing, not null. Avoid using identifiers that conflict with keywords of widely used programming languages. 4. The simplest, but also most often missed opportunity for making frameworks self-documenting is to reserve simple and intuitive names for types that developers are expected to use (instantiate) in the most common scenarios. Framework designers often “burn” the best names for less commonly used types, with which most users do not have to be concerned. For example, a type used in mainline scenarios to submit print jobs to print queues should be named Printer, rather than PrintQueue. Even though technically the type represents a print queue and not the physical device (printer), from the scenario point of view, Printer is the ideal name as most people are interested in submitting print jobs and not in other operations related to the physical printer device (such as configuring the printer). If you need to provide another type that corresponds, for example, to the physical printer to be used in configuration scenarios, the type could be called PrinterConfiguration or PrinterManager. Similarly, names of most commonly used types should reflect usage scenarios, not inheritance hierarchy. Most users use the leaves of an inheritance hierarchy almost exclusively, and are rarely concerned with the structure of the hierarchy. Yet, API designers often see the inheritance hierarchy as the most important criterion for type name selection. For example, naming the abstract base class File and then providing a concrete type NtfsFile works well if the expectation is that all users will understand the inheritance hierarchy before they can start using the APIs. If the users do not understand the hierarchy, the first thing they will try to use, most often unsuccessfully, is the File type. While this design works well in the object-oriented design sense (after all NtfsFile is a kind of File) it fails the usability test, because “File” is the name most developers would intuitively think to program against. Classes vs. Interfaces 5. In general, classes are the preferred construct for exposing abstractions. The main drawback of interfaces is that they are much less flexible than classes when it comes to allowing for evolution of APIs. Once you ship an interface, the set of its members is fixed forever. The only way to evolve interface-based APIs is to add a new interface with the additional members. A class offers much more flexibility. 6. Abstract types do version much better, then allow for future extensibility, but they also burn your one and only one base type. Interfaces are appropriate when you are really defining a contract between two objects that is invariant over time. Abstract base types are better for define a common base for a family of types. 7. When a class is derived from a base class, I say that the derived class has an IS-A relationship with the base. For example, a FileStream IS-A Stream. However, when a class implements an interface, I say that the implementing class has a CAN-DO relationship with the interface. For example, a FileStream CAN-DO disposing. Methods vs. Properties There are two general styles of API design in terms of usage of properties and methods: method-heavy APIs, where methods have a large number of parameters and the types have fewer properties, and property-heavy APIs, where methods with a small number of parameters and more properties to control the semantics of the methods. 8. All else being equal, the property-heavy design is generally preferable. 9. Properties should look and act like fields as much as possible because library users will think of them and use them as though they were fields. 10. Use a method, rather than a property, in the following situations:  - The operation is orders of magnitude slower than a field access would be. If you are even considering providing an asynchronous version of an operation to avoid blocking the thread, it is very likely that the operation is too expensive to be a property. In particular operations that access the network or the file system (other than once for initialization) should likely be methods, not properties.  - The operation returns a different result each time it is called, even if the parameters don’t change. For example, the Guid.NewGuid method returns a different value each time it is called.  - The operation has a significant and observable side effect. Notice that populating an internal cache is not generally considered an observable side effect.  - The operation returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of an internal array so that the user cannot change the internal state. This may lead to inefficient code. Events 11. Consider using a subclass of EventArgs as the event argument, unless you are absolutely sure the event will never need to carry any data to the event handling method. If you ship an API using EventArgs directly, you will never be able to add any data to be carried with the event without breaking compatibility. If you use a subclass, even if initially completely empty, you will be able to add properties to the subclass when needed. Enums 12. Use enums if otherwise a member would have two or more Boolean parameters. Enums are much more readable when it comes to books, documentation, source code reviews, etc. Consider a method call that looks as follows. FileStream f = File.Open (“foo.txt”, true, false); This call gives the reader no context with which to understand the meaning behind true and false. The call would be much more usable if it were to use enums, as follows: FileStream f = File.Open(“foo.txt”, CasingOptions.CaseSensitive, FileMode.Open); Some would ask why we don’t have a similar guideline for integers, doubles, etc. Should we find a way to “name” them as well? There is a big difference between numeric types and Booleans. You almost always use constants and variables to pass numeric values around, because it is good programming practice and you don’t want to have “magic numbers”. However, if you take a look at real life source code, this is almost never true of Booleans. 80% of the time a Boolean argument is passed in as a literal constant, and its intention is to turn a piece of behavior on or off. We could alternatively try to establish a coding guideline that you should never pass a literal value to a method or constructor, but I don’t think it would be practical. I certainly don’t want to define a constant for each Boolean parameter I’m passing in. Methods with two Boolean parameters, like the one in the example above, allow developers to inadvertently switch the arguments, and the compiler and static analysis tools can't help you. Even with just one parameter, I tend to believe it's still somewhat easier to make a mistake with Booleans ... let's see, does true mean "case insensitive" or "case sensitive"?   Sources 1. MSDN 'Design Guidelines for Developing Class Libraries' 2. Krzysztof Cwalina, Brad Abrams 'Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries'

Posted by Vitalii Tsybulnyk on Thursday, August 26, 2010 2:07 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Успешная человеческая многозадачность в софтверной разработке

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

Posted by Vitalii Tsybulnyk on Sunday, June 27, 2010 6:29 PM
Permalink | Comments (2) | Post RSSRSS comment feed

The Surprising Truth About What Motivates Us

The Royal Society for the Encouragement of Arts, Manufactures and Commerce (RSA) recently published a very impressive video of Dan Pink presenting the surprising truth about what motivates us. This video is definitely worth spending 40 minutes of your life watching it, but there is also a very nice smaller 10-min animated version of it for those who'd prefer to know a short summary instead of a whole story. Dan's talk is built around the problem of motivation. The first surprising 'truth' he discovers is that money is not, in fact, a real motivator in the present world. Money is only a good motivator for simple, straightforward jobs. For creative, complex jobs an absence of money is a demotivator, however once you pay enough, it stops being a motivator at all. What are the real motivators then? They are: AUTONOMY - our desire to be self-directed. The traditional goal of management, 'to control', was invented in 1850's and simply doesn't work in a today's world of complex creative jobs. MASTERY - our desire to make progress, to get better at what we do. This is one of the most significant components of our satisfaction from work. PURPOSE - we want to be a part of something bigger, something that makes world better. Dan provides many very impressive examples and research results, so I'd recommend watching the original video to get your own impression.

Posted by Vitalii Tsybulnyk on Wednesday, June 9, 2010 10:08 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Офисная байка про муравья

Не встретил никакой информации о правах на текст, так что привожу его здесь без правок и изменений.   Офисная байка про муравья Каждый день, с утра по раньше приходил на работу продуктивный и весёлый МУРАВЕЙ. Была у него хорошая производительность и весёлым он был. И деятельность фирмы была успешной но... ШМЕЛЬ, генеральный директор фирмы где работал МУРАВЕЙ, решил, что МУРАВЕЙ не может работать сам по себе, так что была создана должность надсмотрщика и нанял он НАВОЗНОГО ЖУКА. Самой главной заботой ЖУКА - НАВОЗНОГО была организовать работу МУРАВЬЯ. И заставил он МУРАВЬЯ делать отчёты о ежедневной проделанной работе. Вскоре понадобилась должность секретаря, который бы помог жуку в чтении и регистрации отчётов МУРАВЬЯ. Поэтому наняли ПАУЧИХУ, которая классифицировала документы и отвечала на телефонные звонки. Между тем, счастливый МУРВЕЙ работал, работал, работал... ШМЕЛЬ, был очень доволен отчётами НАВОЗНОГО ЖУКА, так что запросил дополнительные отчёты, прогнозы и расчёт различных показателей. В таком случае, необходимо было нанять ТАРАКАНА в качестве ассистента НАВОЗНОГО ЖУКА. ... а также купить компьютер и цветной принтер. Вскоре, производительный и счастливый МУРАВЕЙ, начал жаловаться на все разборки и отчёты который должен был предоставлять, и всё менее веселей ему становилось. ШМЕЛЬ, генеральный директор, понимает, что необходимо принимать меры. Так что, на месте где работал продуктивный и ещё весёлый МУРАВЕЙ бал создан департамент. На должность начальника был назначен КУЗНЕЧИК. Он соорудил себе современный кабинет и оборудовал соответственно. Новому начальнику департамента понадобился ассистент, который помог бы ему в подготовке стратегических планов и бюджета департамента в котором работал продуктивный и весёлый МУРАВЕЙ. Но МУРАВЕЙ уже не пел как раньше и становился всё более раздражительным... Однажды, генеральный директор, посмотрев на цифры, понял, что департамент где работает МУРАВЕЙ, не является уже таким же рентабельным как раньше. Подумав, ШМЕЛЬ решил нанять в качестве консультанта СОВУ, для проведения диагностики. СОВА просидела 3 месяца на фирме, и, после изучения дела, сделала заключение: "В департаменте слишком много персонала.." ...следуя совету специалиста, провели сокращение численности. МУРАВЕЙ оказался первым в списке, т.к. всё время был недоволен... Мораль: Даже и не думай быть счастливым и продуктивным муравьём. Лучше быть некомпетентным и бесполезным. Некомпетентным не нужны надсмотрщики,... все и так понимают почему. И, если, несмотря на твои "усилия", ты всё же продолжаешь оставаться продуктивным, не показывай ни за что на свете что ты счастлив и весел. Тебе этого никогда не простят. Но если вопреки сказанному выше, ты упрямо продолжаешь оставаться СЧАСТЛИВЫМ И ПРОДУКТИВНЫМ МУРАВЬЁМ, работай на себя, так чтобы не нести на своей спине шмелей, навозных жуков, тараканов, пауков, кузнечиков и сов.   И хотя я не совсем согласен с выводами в разделе "Мораль", многие события из байки честенько имеют место в реальной жизни...

Posted by Vitalii Tsybulnyk on Wednesday, May 19, 2010 5:03 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Рейнджеры и солдаты: о подчинении в софтверной индустрии

В мартовском номере российского журнала "Управление проектами" вышла статья вашего покорного слуги "Рейнджеры и солдаты: о подчинении в софтверной индустрии". То, что начиналось как пост в блоге, неожиданно переросло в полноценную статью. К сожалению, журнал не предоставляет доступ к тексту статьи в электронном виде, ограничившись аннотацией, так что желающим прочитать статью полностью похоже прийдётся приобрести журнал :-( Основное внимание при рассмотрении вопросов управления проектами как правило уделяется поведению менеджера, при этом подчинение, как неотъемлемая часть процесса управления, часто ускользает из поля зрения специалистов. Предлагается рассмотреть два принципиально разных типа подчинения: подчинение типа 'Солдат' (безоговорочное подчинение, при котором от подчинённого не требуется понимания назначения и смысла его действий) и подчинение типа 'Рейнджер' (обсуждение задач и путей их реализации с последующим добровольным принятием на себя обязанностей по их выполнению). Констатируется важность и востребованность обоих типов подчинения в различных софтверных проектах, а также недостаточное внимание к подготовке технических специалистов с целью овладевания обоими типами подчинения.

Posted by Vitalii Tsybulnyk on Friday, April 2, 2010 11:59 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Основные антипаттерны в софтверной разработке

Антипаттерны организации и управления: Аналитический паралич (Analysis paralysis): Неоправданное внимание и затраты времени/ресурсов на стадию анализа. Дойная корова (Cash cow): Прибыльный и успешный продукт, высокая прибыль от которого зачастую приводит к чрезмерной расслабленности в разработке новых версий продукта или новых продуктов. Разработка комитетом (Design by committee): Результат вклада в разработку многих участников, но отсутствие единого видения. Эскалация обязательств (Escalation of commitment): Неспособность отказаться от решения даже когда доказана его ошибочность. Драконовские меры (Management by perkele): Авторитарный стиль управления, отвергающий инакомыслие. Moral hazard: Отделение человека, принимающего решения, от последствий этих решений. Управление грибами (Mushroom management): Стиль управления, при котором работникам предоставляется минимум информации и эта информация искажается (управлять грибами - содержть в темноте и прикрмливать навозом) . Управление основанное на числах (Management by numbers): Уделение избыточного внимания численным критериям управления, когда они неважны или стоимость их получения слишком высока Дымоход (Stovepipe): Организационная структура, при которой потоки информации циркулируют преимущественно вверх-вниз, но не горизонтально, между подразделениями. Замкнутость на продавце (Vendor lock-in): Чрезмерная зависимость системы от внешней компоненты. Сваливание расходов (Cost migration): Перенос расходов на проект к уязвимому отделу или бизнес-партнёру. Путь камикадзе (Death march): Все знают, что проект обречён, кроме главы, вплоть до "дня X". Также применяется для стиля руководства, когда сотрудники вынуждаются к сверхурочной работе для достижения нереальных сроков. Расползание рамок (Scope creep): Дозволение рамкам проекта расти без должного контроля. Groupthink: Никто не хочет выдвигать идеи, противоречащие комфортному консенсусу. Дым и зеркала (Smoke and mirrors): Демонстрация заказчику заранее заготовленных "обманок" вместо рабочей функциональности. Раздувание ПО (Software bloat), Функции для галочки: Каждая следующая версия продукта требует всё больше системных ресурсов без явной выгоды для пользователя. Ползущий улучшизм (Creeping featurism): Добавление новых улучшений в ущерб качеству системы. Продолжительное устаревание (Continuous obsolescence): Выделение непропорционально больших усилий портированию системы в новые окружения. Bystander apathy: Дизайн или требования неверны, но те, кто это знают, ничего не предпринимают по этому поводу, т.к. для этого необходимо вовлечение большего числа людей. Tester Driven Development: Новые требования к продукту возникают из отчётов об ошибках. Я тебе это говорил (I told you so): Когда игнорируется предупреждение эксперта, являющееся оправданным Единственный знающий человек (Single head of knowledge): ЕЗЧ (SHOK) применим в том случае, когда единственная личность во всей организации контролирует жизненно-важную область ноу-хау или информации о внутренностях системы. Рыцарь на белом коне (Knight in shining armor): РНБК (KISA) происходит тогда, когда личность, которая не совершает ошибок, появляется на сцене и пытается починить всё, без сообщений о том, какие изменения он/она сделал/сделает и почему. Gold plating: Работа над проектом после момента, когда уже усилия перестают приносить прибыль или создавать добавочную стоимость. Антипаттерны дизайна и реализации:  Большой комок грязи (Big ball of mud), Проблема йо-йо (Yo-yo problem), Спагетти-код (Spaghetti code): Структура системы отсутствует или трудно поддаётся пониманию. Бензиновая фабрика (Gas factory), Ненужная сложность (Accidental complexity), Inner-platform effect, Раздувание интерфейса (Interface bloat): Неоправданное усложнение дизайна системы, излишняя гибкость или универсальность. Инверсия абстракции (Abstraction inversion): Не предоставление реализованных функций, необходимых пользователям, что вынуждает их реализовывать эти функции заново с помощью функций более высокого уровня. Database-as-IPC: Использование базы данных для обмена соосбщениями между процессами там, где можно использовать более легковесные способы. Затычка на ввод данных (Input kludge): Отсутствие коректной обработки возможного неверного ввода. Магическая кнопка (Magic pushbutton): Написание бизнес-логики в коде пользовательского интерфейса (например в обработчике события нажатия на кнопку). Гонки (Race hazard):Ошибка в определении последовательности различных порядков событий. Базовый класс-утилита (BaseBean): Наследование класса-утилиты вместо делегирования к нему. Вызов предка (Call super): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка. Circular dependency: Ненужная прямая или непрямая взаимная зависимость между объектами или модулями. Блоб (Blob), Божественный объект (God object): Концентрация слишком большого количества функций в одиночной части дизайна (классе). Объектная клоака (Object cesspool): Повторнае использование объектов, чьё состояние не удовлетворяет (возможно неявным) условиям повторного использования. Паблик Морозов (Object orgy): Предоставление неоправданного доступа к внутренним свойствам объекта. Полтергейст (Poltergeists): Объекты, чьё единственное предназначение — передавать информацию другим объектам. Sequential coupling: Класс, требующий вызова его методов в строго определённом порядке. Действие на расстоянии (Action at a distance): Неожиданное взаимодействие между далёкими частями системы. Накопить и запустить (Accumulate and fire): Установка параметров подпрограмм в наборе глобальных переменных. Слепая вера (Blind faith): Недостаточная проверка корректности исправления ошибки или результата работы подпрограммы. Лодочный якорь (Boat anchor): Сохранение более не используемой части системы. Активное ожидание (Busy spin): Потребление ресурсов процессора во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать систему сообщений. Cargo cult programming: Использование паттернов и методик без понимания причин. Проверка типа вместо интерфейса (Checking type instead of membership, Checking type instead of interface): Проверка того, что объект имеет специфический тип в то время, когда требуется только определённый интерфейс. Инерция кода (Code momentum): Сверхограничение части системы путём постоянного подразумевания её поведения в других частях системы. Кодирование путём исключения (Coding by exception): Добавление нового кода для поддержки каждого специального распознанного случая. Таинственный код (Cryptic code): Использование аббревиатур вместо мнемоничных имён. Error hiding: Перехват сообщения об ошибке до того, как она показывается пользователю, в следствие чего пользователь не получает сообщения об ошибке или получает бессмысленное сообщение. Expection handling: Использование системы исключений для реализации бизнес-логики системы. Жёсткое кодирование (Hard code): Внедрение предположений об окружении системы в слишком большом количестве точек её реализации Мягкое кодирование (Soft code): Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование. Поток лавы (Lava flow): Сохранение нежелательного (излишнего или низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия. Loop-switch sequence: Кодирование последовательности шагов с помощью цикла и оператора выбора (switch). Магические числа (Magic numbers): Включение чисел в алгоритмы без объяснений. Программирование методом копирования-вставки (Copy and paste programming): Копирование (и лёгкая модификация) существующего кода вместо создания общих решений. Дефакторинг (De-Factoring): Процесс уничтожения функциональности и замены её документацией. Золотой молоток (Golden hammer, Silver bullet):  Сильная уверенность в том, что любимое решение универсально применимо. Фактор невероятности (Improbability factor): Предположение о невероятности того, что сработает известная ошибка. Преждевременная оптимизация (Premature optimization): Оптимизация на ранних стадиях в ущерб хорошему дизайну, сопроводимости и иногда даже реальной эффективности системы. Programming by permutation (или "programming by accident"): Попытка достижения нужного результата путём последовательного изменения кода и проверки помогает ли это. Изобретение колеса (Reinventing the wheel): Разработка собственного решения вместо применения существующего. Изобретение квадратного колеса (Reinventing the square wheel): Создание собственного плохого решения, когда существует хорошее. Ад зависимостей (Dependency hell), DLL-ад (DLL hell): Проблемы с совместно испльзуемыми билиотеками по причине различий в версиях одной и той же библиотеки   Источники 1. Anti-pattern on wikipedia.org 2. Антипаттерн на wikipedia.org

Posted by Vitalii Tsybulnyk on Tuesday, December 22, 2009 4:27 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Учимся делегировать

Старая истина гласит “Если хочешь сделать что-то хорошо - сделай это сам”, однако это не всегда верно, когда дело касается управления проектами. Важно всегда помнить, что вы не можете всё сделать сам или "клонировать себя", поэтому умение делегировать является неотъемлемой характеристикой успешного руководителя проекта. Для некоторых руководителей делегирование воспринимается как потеря контроля (а значит и власти), ведь в конце концов ответственность за успешное выполнение задач лежит на руководителе. Однако помните, что власть должна исползоваться крайне осторожно, и делегирование "под постоянным контролем" может встретить сопротивление или даже саботаж в команде. Сохранение балланса между контролем и делегированием есть одно из ключевых умений хорошего руководителя. Вы должны использовать минимальное количество власти и контроля, необходимое для должного результата. Частые проверки прогресса важны для того, чтобы устранить проблемы как можно раньше, но слишком много проверок может быть интерпретировано как недоверие. Начните с минимального контроля и повышайте его если чувствуете что этого недостаточно. Никогда не злоупотребляйте своей властью и не пользуйтесь властью для личной выгоды, в особенности если вам никто не давал такого права. Когда делегируете обязанности и власть, старайтесь давать людям выбор, однако перед этим убедитесь, что все варианты приемлемы для вас, и не давите если выбор был сделан не так, как вам хотелось бы. Помните также, что уважение - залог успешного делегирования, и при отсутствии должной доли уважения делегирование может быть практически неосуществимой задачей. Существует несколько способов заслужить уважение подчинённых. Прежде всего, демонстрируйте способность и желание выполнять задачи самому, делегирование не должно выглядеть так, как будто вы просто сбрасываете на кого-то работу, которую не хотите делать сами. Далее, делитесь с подчинёнными общим планом действий и важностью задач вцелом, это даст возможность понять ценность задач для успеха проекта и относиться к ним более серьёзно. Старайтесь, чтобы работа помогала вашим подчинённым в достижении их собственных целей и интересов, а не только интересов проекта. Следующее не менее важное условие успешного делегирования - руководитель должен хорошо знать свою команду, чтобы не только хорошо понимать потребности и предпочтения каждого участника, но и эффективно использовать сильные стороны своих подчинённых, а также избегать ситуаций, когда задачу поручают тому, кто с ней заведомо не справится. И наконец, вознаграждайте за успешное выполнение задачи, однако помните, что похвала приносит пользу только если она сказана искренне. Как только вы начнёте успрешно применять все перечисленные стратегии, ваше руководство превратится в то, чем оно и должно быть: дайте другим людям возможность принимать решения и воплощать их в жизнь, в то время как вы, как руководитель проекта, контролируете среду протекания этого процесса.   Источники 1. Become Better at Delegation on www.project-management-knowledge.com 2. Delegate Without Losing Control on www.project-management-knowledge.com

Posted by Vitalii Tsybulnyk on Wednesday, December 16, 2009 5:54 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Искусство "хаопорядоченного" лидерства

Рассуждая в своей работе [1] о лидерстве и руководстве в современных командах и организациях, Ди Хок вводит понятие "хаопорядоченного" ('chaord' = 'chaos' + 'order') лидества. По его мнению, успешное руководство в самоорганизующихся, самоуправляющих, адаптивных, нелинейных, сложных организмах, коими являются современные огранизации и команды, должно гармонично сочетать многие зачастую противоречивые характеристики: хаоса и порядка, соперничества и взаимопомощи, теоретических знаний и практических умений. Результатами его умозаключений является перечень замечательных рекомендаций, которым по моему мненю должен следовать любой успешный лидер: - Власть: Власть никогда не используется. Если вы пользуетесь властью - вы никогда реально ею не обладаете. - Человеческие отношения: Когда имеете дело с подчинёнными, повторяйте про себя: "Ты для себя так же хорош, как и я для себя, следовательно мы равны". Когда имеете дело с вышестоящими, повторяйте про себя: "Я для себя так же хорош, как и ты для себя, следовательно мы равны". - Критицизм: Активная критика - это ценнейшее приобретение. Она позволяет без малейших затрат времени и усилий устранить наши промахи и ошибки, а альтернативным решениям быть высказанными. Мы только должны слушать внимательно, отсеивая всё, что идёт от незнания, зависти или злобы, и выделяя то, что действительно ценно. - Компенсация: Деньги не мотивируют ни лучших людей, ни лучшее в людях. Они могут арендовать тело и влиять на сознание, но они не могут тронуть сердце или душу, это подвластно только доверию, принципам и этике. - Эго, Зависть, Жадность и Амбиции: Четыре зверя, которые неизбежно поглощают своего хозяина. Задумаете прокатиться на их спинах - и вы закончите у них в желудке. - Должность: Считаете что подчинённые дожны мерять степень своего повиновения превосходством Вашей должности? К сожалению, при этом Вы теряете то уважение, которое Вы могли бы заслужить у них своим ежедневным вкладом, а без их уважения Ваше превосходство и влась деструктивны. - Ошибки: Маленькие беззубые зверьки, которых вы можете распознать, признать, исправить, научиться на них, и перерасти их. Если же нет, то они отращивают клыки и наносят смертельный удар. - Выполнение: Никогда не путайте активность и продуктивность. Важно не то, что происходит на вашем конце трубы, а то, что выходит из другого конца. Всё, кроме мыслей, суждений и дейтствий, так или иначе инфицировано бессмысленной деятельностью. Думайте! Рассуждайте! Действуйте! Дайте возможность другим делать то же! - Наем: Никогда не нанимайте или повышайте по собственному подобию. Глупо дублировать свои сильные стороны, но ещё глупее плодить свои слабости. Нанимайте, доверяйте и вознаграждайте тех, чья переспектива, способности и суждения радикально отличаются от Ваших. Приготовьтесь к тому, что для этого нужны выдающиеся скромность, толерантность и мудрость. - Креативность: Проблема заключается не в том, как вызвать новые, инновационные мысли в вашей голове, а в том, как выбросить старые прочь. Каждый ум - как здание, наполненное архаичной мебелью. Очистите уголки вашего сознания - и креативность быстро заполнит их. - Слушайте: Вы можете узнать многое, внимательно слушая что люди говорят, но ещё больше можно узнать из того, что люди не говорят. Слушайте тишину так же внимательно, как и звуки. - Суждения: Суждения - это мускулы, которые сознание тренирует через использование. Вы ничего не теряете, доверяя им. Если вы доверились им, и они оказались плохими, Вы быстро поймёте и улучшите их. Если Вы доверяли им, и они оказались верными - Вы быстро преуспеете. Если же они были верными, но Вы не доверились им - Вы будете горько об этом жалеть, т.к. были правы, но последовали чужим неверным суждениям к провалу. - Руководство: Управляйте собой, управляйте своими руководителями, управляйте равными себе и дайте своим людям делать то же самое.   Источники 1. Dee Hock The Art of Chaordic Leadership

Posted by Vitalii Tsybulnyk on Wednesday, December 2, 2009 4:24 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Как отстреливается большинство хороших идей

Очень наглядный эксперимент для демонстрации факта "отстрела" большинства хороших идей провёл Мэтью Мэй и описал результаты в своей работе [1]. На одном из проводимых им тренингов присутствовало около 75 человек с большим диапазоном старшинства от руководителей команд до топ-менеджеров, причём Мэтью зарание собрал и огласил информацию о степени старшинства каждого из присутствующих. Изначально упражнение заключалось в демонстрации "коллективного разума", когда "мы" оказывается умнее чем "я", и основывалось на сравнении результатов решения сложной проблемы коллективно и индивидуально. В качестве проблемы была выбрана известная "Проблема выживания на Луне", у которой есть правильное решение, предложенное и детально аргументированное NASA. Мэтью внёс в упражнение следующее изменение: на каждом столе он выбрал представителя с самой низкой должностью и сделал из них "подсадный уток", предварительно сообщив им правильное решение и его объяснение. Однако их задача при этом не изменилась - убеждать всех остальных более высокопоставленных членов команды в правильности своего решения. По итогом коллективного решения проблемы ни одна из команд не дала в итоге верного ответа. После последующего индивидуального решения проблемы Мэтью попросил встать тех, кто дал верный ответ (т.е. "подсадный уток") и объявил, что это те люди, кто предлагали верный ответ, но их идеи были задавлены или проигнорированы, вероятнее всего по причине их низкого ранга. "Я жалею что у меня не было на тот момент камеры, чтобы заснять багровые лица менеджеров" - пишет Мэтью. Конечно, этот эксперимент носил некоторую долю розыгрыша, однако проблема от этого не исчезает и не становится менее серьёзной. Более формальное исследование вопроса "отстрела" хороших идей изложено в [2].   Источники 1. Matthew E. May 'Mind of the Innovator: Taming the Traps of Traditional Thinking' 2. Michael Iva '100 Ways to Kill a Concept: Why Most Ideas Get Shot Down'

Posted by Vitalii Tsybulnyk on Tuesday, November 24, 2009 4:14 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Документирование и распределённый мозг команды разработчиков

Вопрос документирования в процессе разработки бесспорно заслуживает пристального внимания как один из наиболее важных. Мне столько раз приходилось слышать сетования на недостаточную документированность требований или технических решений, что наверно уже давно пора было бы принять решение "чем больше документации - тем лучше". Однако я бы с таким решением не спешил. Дело в том, что (как показывает практика) большинство софтверных проектов - это далеко не реализация точно заданных требований по заранее определённым техническим методикам. Такая удача - удел академической науки либо госзаказ для военной или космической программы. Большинство же современных коммерческих софтверный проектов активно эксплуатируют "софт"-составляющую процесса, а именно: и бизнес-, и технические требования к проекту как правило меняются очень динамично. Ответом на это стало появление динамических методологий, основная масса которых относится к документированию приблизительно следующим образом: "Документирования нужно ровно столько, сколько решит команда и спонсор для данного конкретного проекта" [1]. Второе открытие динамических методологий заключается в том, что документирование может быть выражено в различных формах. Наследие инженерных дисциплин сводило документирование к узкому классу инженерных артифактов, а именно "инструкция (алгоритм)" и "чертёж (диаграмма)". Большинство же гибких методологий, протестуя против инженерной сути софтверной разработки, предлагает более вольное трактование понятия "проектная документация" и включают в него все возможные артифакты, способные служить метками, по которым можно восстановить суть ценной для проекта информации, начиная c салфеток с набросками пользовательского интерфейса и заканчивая фотографиями доски или даже видеозаписями митингов или дискуссий [2]. Думаю для любого, кто хоть раз пытался поддерживать детальную "инженерную" документацию динамичного софтверного проекта в актуальном состоянии, данная идея звучит весьма заманчиво. Конечно же, она основана на том, что все вместе участники проекта на самом деле обладают всей необходимой информацией, им только нужны своего рода "ссылки" или маркеры, которые могут направить их к человеку, владеющему интересующей вас в данный момент порцией технических или маркетинговых деталей. Мне это напоминает гипотезу о распределеноом мозге муравьиной семьи, только здесь роль такой семьи выполняет команда по разработке софта. Из этой модели следуют и очевидные рамки её применимости:  - Чем хуже коммуникации, тем больше нужно маркеров, например для эффективной работы удалённой команды этих маркеров нужно больше всего.  - Чем строже формализм, тем больше нужно формальных документов взамен "распределённого знания", например для военных разработок роль "распределённого разума" незначительна.  - Чем выше риск потери части "распределённого знания" (уход или долгое отсутствие сотрудников), тем выше должно быть дублирование этих знаний и тем больше маркеров приходится задействовать.   - Чем больше новичков приходится подключать к проекту, тем больше маркеров и тем подробнее эти маркеры.   Источники 1. Alistair Cockburn 'How many work products are needed in software development?' 2. Alistair Cockburn 'The end of software engineering and the start of economic-cooperative gaming'

Posted by Vitalii Tsybulnyk on Sunday, September 13, 2009 7:13 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Лучшие практики удалённой разработки

К сожелению или к счастью, но оффшорный аутсорсинг и аутстаффинг уже стали неотъемлемой частью бизнес-модели современной разработки ПО. Ими пользуются компании всех "рангов" - от стартапов с командой из двух человек до софтверных гигантов. Обсуждение преимуществ и недостатков таких тенденций выходит за рамки данного поста, однако с учётом сложившейся ситуации мне представляется ценным сформулировать основные советы и рекомендации участникам процесса удалённой разработки. За последные несколько лет я побывал пожалуй во всех возможных ролях этого процесса, так что накопил некоторый собственный опыт в данной области, к тому же сегодня я буду апеллировать к наработкам ведущих мировых авторитетов [1]. Начну я с той ошибки, которую поначалу допускают многие: "В условиях нашей конкретной задачи переход на удалённую разработку ничего не меняет".  Каковы бы ни были условия вашей задачи, процесс удалённой работы радикально изменяет модели поведения участников такого процесса и их ощущения во время работы. Это не только подтвердит вам любой руководитель или разработчик, работавший удалённо, но и очевидно следует хотябы из того факта, что именно коммуникации (которые играют основную роль в процессе и несут основной вклад в успех) изменяются больше всего при переходе на удалённую работу. Нужно заметить, что большинство приведенных ниже рекомендаций хорошо бы соблюдать не только для удалённой разработки, однако именно расстояние делает их особенно важными:  - Старайтесь разделять команды по функциональности и модулям, а не по ролям - удалённая команда QA конечно тоже имеет право на существование, однако когда разработчик и тестировщих находятся близко друг к другу, эффективность растёт.  - Если кодом совместно владеют удалённые команды, то ежедневно собирайте автоматические билды - это позволит сделать вносимые изменения более прозрачными, а также оперативно устранять "поломанные билды" и юнит-тесты.  - Используйте вики для хранения общей информации. Рассчитывайте, что вам понадобится более детальное документирование.  - Пользуйтесь тестовыми скриптами для лучшего понимания требований - нет ничего более понятного для разработчика, чем код.  - Проводите совместные митинги по планированию итераций и регулярные статус-митинги.  - Комбинируйте различные виды коммуникаций - IM, аудиоконференции, видеоконференции, электронная почта, вики могут дать намного больший эффект при совместном использовании.  - Регулярно посылайте представителей от обеих сторон с личным визитом друг к другу - это позволяет улучшить комуникации, построить доверие и усилить обе команды.  - Бойтесь недооценить культурные, региональные и языковые различия - сюрпризы могут поджидать вас там, где вы даже не подозреваете.   Источники  1. Martin Fowler 'Using an Agile Software Process with Offshore Development'

Posted by Vitalii Tsybulnyk on Friday, September 11, 2009 2:21 PM
Permalink | Comments (0) | Post RSSRSS comment feed