Размышлизмы eao197: 19 июля 2009 г.

суббота, 25 июля 2009 г.

[life; comp] Наболевшее. О работе со студентами вообще и об обязательном распределении в частности

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

Я сам начинал работать в начале 5-го курса. Как мне теперь кажется, это сложно было назвать работой. Потом я сам и наблюдал за работой других студентов/выпускников, и занимался селекцией студентов, и даже пробовал вести курсы для студентов по программированию. Поэтому некоторый опыт у меня есть. Хочется надеяться, что в столичных ВУЗах ситуация иная. Иначе уж совсем уж…

Работу со студентами можно охарактеризовать всего одним словом: непредсказуемость. Невозможно предугадать, будет ли выполнено выданное студенту задание, когда оно будет выполнено и насколько хорошо. Поскольку:

главное для студента – все же учеба. Лабораторные, курсовые, зачеты, экзамены. Чем больше грузят студента, тем меньше возможностей у него работать. В последние годы на студентов, как мне видится, нагрузка совсем уж запредельная. По каждому предмету чуть ли не еженедельные лабораторные. А объяснение простое – зарплата преподавателей поставлена в прямую зависимость от количества проведенных лабораторных работ.
ВУЗы не учат работать. Да вот так и именно так. ВУЗы учат учится, дают какой-то базовый материал, в лучшем случае “школу”. Но ни студенты, ни выпускники не умеют работать. Хорошо, если они хотя бы умеют сносно программировать. Но и с этим в последние годы все хуже и хуже.

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

Так зачем брать студентов на работу? Главная задача – селекция и воспитание кадров. Только в процессе реальной работы можно понять, что из себя представляет программист. Насколько он вменяем, насколько он коммуникабелен, насколько он ответственен, самостоятелен и т.д. и т.п. Если попадается стоящий человек, то работа станет для него еще одной формой обучения. Только учится он будет уже не теории, а практике. И, кроме того, он будет входить в курс дела. Погружаться в проблемы, которыми ему придется заниматься после окончания ВУЗа. Т.е. весь этот геморрой со студентами оправдывается и окупается сторицей, если из 3-4 нанятых студентов один в конце-концов будет нормально работать. Но!

Но у нас в Белоруссии есть обязательное распределение для тех, кто учился на бюджете. Т.е. окончил ВУЗ, поди отработай два года там, куда тебя направили. Особенно трагично это в случаях, когда у ВУЗа есть свои бзики. Скажем, находящийся рядом с нами Белорусский Государственный Университет Транспорта (БелГУТ, бывший ранее известным брендом – БелИИЖТом) распределяет выпускников только в организации, в которых есть доля государственной собственности. Другая кузница программистких кадров в Гомеле – Гомельский Государственный Университет (ГГУ, который я сам когда-то давно заканчивал) в этом вопросе гораздо практичнее – где студент смог договориться о трудоустройстве, туда его и распределяют.

В результате со студентами из БелГУТа обычной становится история, когда студент работает у нас год-два, более-менее осваивает программирование, а потом попадает под ~~раздачу~~распределение и идет отбывать двухлетний патриотический долг. В лучшем случае работая с нами как совместитель, в свободное от основной работы время.

В общем, самое мягкое, что я могу сказать про наше обязательное распределение, – это маразм. В мое время (1995-й год) распределение и статус “молодого специалиста” были средством защиты выпускника. Понятно было, что такие спецы мало кому нужны – учи их, трать на них силы и время, когда работать нужно. В условиях рыночных отношений, прошу заметить. А сейчас распределение – это вовсе не защита выпускника. Это его сдача в рабство на пару лет.

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

Да, я знаю, про аргумент “отучился за государственные деньги, пусть теперь государству долг вернет”. Это такой же маразм. Почему? Да потому, что вложение государства в образование выгодно самому государству. По крайней мере, должно быть выгодно. Как ни крути, а создавать высокотехнологичные продукты (к коим можно отнести и программное обеспечение) должны образованные люди.

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

Учат людей учиться. Как хорошо показано в анекдоте:
выпускник школы на вопрос “Что такое гугол?” отвечает “Не знаю!”, выпускник ВУЗа на тот же вопрос отвечает “Я не знаю, но я могу это узнать”. Попутно ВУЗы отсеивают тех, кто не способен или не желает учиться учиться.
Отбирают тот редкий процент одаренных и амбициозных индивидов, которым следует заниматься наукой. И предоставляет им такую возможность посредством дальнейшей аспирантуры и пр.

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

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

Такие, блин, дела.

четверг, 23 июля 2009 г.

[comp.flame] 21 июля, Москва, Сбербанк: страшный сон разработчика 24x7 систем

В понедельник, 21 июля 2009 года, в Москве воплотился в жизнь кошмарный сон разработчиков систем, которые должны работать в режиме 24x7: на несколько часов была заблокирована выдача вкладов и пенсий в 250 московских отделениях Сбербанка. Если верить этому источнику, то причиной стала новая версия ПО, введенная в эксплуатацию накануне, в воскресенье. Которая не выдержала реальной нагрузки. И вместо нее пришлось запускать старую версию, остановив для этого работу всех отделений Сбербанка в Москве.

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

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

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

Какие выводы можно сделать для себя из этой истории? Пожалуй, главных всего два:

Тестирование. Еще раз тестирование. И еще раз тестирование. А потом еще раз тестирование.
При запуске новой версии ПО нужно быть готовым за очень короткое время (лучше всего мгновенно) вернуться к предыдущей версии.
И еще раз тестирование.

Вывода всего два. Но пункта три, поскольку откат к предыдущей версии так же должен быть протестирован. А потом еще раз протестирован.

PS. А вообще у Сбербанка есть нехорошая привычка делать обновления своих систем летом. Когда часть народа в отпусках, а у остальной голова плавится от жары, а мысли заняты подготовкой к своему отпуску.

[comp.prog] C++0x: Concepts R.I.P.

Небольшая хронология событий:

сначала мне попадается статья о ситуации с развитием стандарта C++0x. В которой говорилось, что ни в одном из распространенных C++ компиляторов реализация концептов не сможет начаться раньше 2010-го года. Т.е. даже при самом удачном стечении обстоятельств, концепты реально появились бы только в 2011;
затем в news-группе digitalmars.D.announce Вальтер Брайт (автор компилятора Digital Mars C++ и языка D) сказал, что есть слухи о намерении выбросить концепты из языка. Вообще
ну и в завершении появились сообщения о том, что концепты таки выбросили (вот и вот).

Вот такие дела. С одной стороны грустно, т.к. огромный кусок работы был выброшен (пока, по крайней мере). Но с другой стороны:

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

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

Хочется надеяться, что люди из комитета учтут опыт создания стандартов 1998-го года и C++0x в дальнейшем будут идти другим путем: небольшие ревизии стандарта каждые 3-5 лет, вместо больших ревизий раз в десять лет.

Ну и еще один вывод, уже личный. Приятно, что в этот раз я не пытался “бежать впереди поезда” и изучать стандарт до его принятия.

В заключение ссылки на описания концептов от Бъярна Страуструпа:
Specifying C++ Concepts
Symplifying the use of concepts

Update. Статья Б.Страуструпа о произошедшем: The C++0x "Remove Concepts" Decision. В ней так же можно найти ссылки на различные версии описаний концептов. И список того, что же будет в C++0x (т.е. уже в C++1x).

Еще один update: What Happened in Frankfurt? от Дуга Грегора (разработчика ConceptGCC, источник тут). Из его рассказа у меня сложилось впечатление, почему с концептами ничего не вышло -- было два разных направления, каждое из которых тянула и развивала своя группа. А компромиса в условиях комитета достичь не удалось (если такое вообще возможно).

вторник, 21 июля 2009 г.

[comp.prog.management] Несколько свежих цитат из ДеМарко

Software Engineering: An Idea Whose Time Has Come and Gone? (via thesz)

My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I'm wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.

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

The book's most quoted line is its first sentence: "You can't control what you can't measure." This line contains a real truth, but I've become increasingly uncomfortable with my use of it. Implicit in the quote (and indeed in the book's title) is that control is an important aspect, maybe the most important, of any software project. But it isn't. Many projects have proceeded without much control but managed to produce wonderful products such as GoogleEarth or Wikipedia.

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

Примечательно еще и то, что за последние лет 7-8 мне доводилось наблюдать за развитием целого ряда важных проектов с серьезными заказчиками, в которых сроки изначально устанавливались жестко. Но потом тихой сапой они раздувались, переносились и изменялись. Вероятно, я наблюдал в миниатюре то, о чем говорит ДеМарко:

Consistency and predictability are still desirable, but they haven't ever been the most important things. For the past 40 years, for example, we've tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal.

Но если контролируемость и предсказуемость проектов не важна, то что же тогда важно? А вот что:

The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. We've been rather successful at transformation, often while operating outside our ontrol envelope.

А важно это потому, что проекты делятся на два типа:

To understand control’s real role, you need to distinguish between two drastically different kinds of projects:
* Project A will eventually cost about a million dollars and produce value of around $1.1 million.
* Project B will eventually cost about a million dollars and produce value of more than $50 million.

И контроль более важен для проектов типа A, но почти не важен для проектов типа B. Как следствие чего:

Can I really be saying that it's OK to run projects without control or with relatively little control? Almost. I'm suggesting that first we need to select projects where precise control won't matter so much. Then we need to reduce our expectations for exactly how much we're going to be able to control them, no matter how assiduously we apply ourselves to control.

Ну и возвращаясь к теме You can't control what you can't measure:

Imagine you're trying to control a teenager's upbringing. The very idea of controlling your child ought to make you at least a little bit queasy. Yet the stakes for control couldn't be higher. If you fail in your task, fail utterly, lives can be ruined…
…Now apply "You can't control what you can't measure" to the teenager. Most things that really matter-honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyalty, humor, kindness-aren't measurable. You must steer your child as best you can without much metric feedback. It's hard, but then parenting is hard…
…So, how do you manage a project without controlling it? Well, you manage the people and control the time and money.

После чего следует очень и очень хороший рецепт (насколько я могу судить):

You say to your team leads, for example, "I have a finish date in mind, and I'm not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you've got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go."

PS. Выделение жирным в цитатах мое.

[life.humour] Обалдеть!

Источник с еще несколькими снимками.

воскресенье, 19 июля 2009 г.

[comp.flame] Из непонятого: Клуб Успешных Менеджеров Программистов

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

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

Но что значит “Успешный PM”? Неужели это тот PM, который успешно ведет свои проекты? Так ведь это и есть его работа! Проекты, которые ведет PM должны либо успешно завершаться, либо должны прекращаться по независящим от него причинам. Если же PM заваливает проект или допускает завал из-за собственного неумения вести проекты, то это, прошу прощения, никакой не PM. Т.е. неуспешных PM быть не должно в принципе. Либо человек является PM-ом, либо он им вообще не является. Поэтому “Успешный PM” – это, на мой взгляд, ярко выраженная форма снобизма (в лучшем случае).

Интересно, что толкнуло организаторов данного клуба так его назвать? Может быть, PM-ы так привыкли мотивировать разработчиков посредством мантр “ты самый лучший программист, ты успешный программист” (см. притчу про Тойоту), что они по привычке так же решили себя замотивировать? :-/

PS. Наткнулся на этот клуб в описании впечатлений от конференции Software People 2009. Среди прочего, просмотрел презентацию “Профессиональное и непрофессиональное поведение в команде”. Что-то резануло глаз то, что “профессиональный командный игрок”, среди прочего, “постоянно приобретает профессиональные знания и опыт, выдвигает новые идеи, добивается распространения своих знаний, опыта и идей среди коллег”. Блин, прямо советский агитпром какой-то.

PPS. Я бы ничего не имел против названия “Клуб Удачливых Менеджеров Программистов”. Поскольку это всего лишь констатация факта, что данным менеджерам очень сильно помогает удача (что далеко не всегда плохо).

[comp.prog.humour] Образец профессионального юмора

Нравится мне профессиональный юмор. Например, у программистов (источник):

// Dear maintainer:
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 16
//