Случайно "накопал" ссылку на статью в NYT где Билл Джой говорит:
"The truth is, great software comes from great programmers, not from a large number of people slaving away"
что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру".
И по-моему он ведь прав, как вы думаете ?
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, fplab, Вы писали:
F>Случайно "накопал" ссылку на статью в NYT где Билл Джой говорит: F>
F>"The truth is, great software comes from great programmers, not from a large number of people slaving away"
F>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>И по-моему он ведь прав, как вы думаете ?
Ну да. Так и есть. Великие программы создаются великими программистами.
Плохие программисты соответственно создают плохие программы.
Спорить с этим сложно да и нет смысла.
Еще правда в том, что великих программистов мало,
и они хотят создавать исключительно великие программы.
В то же время очень много разных задач, которые нужно решать сейчас, а не ждать,
когда их решат великие программисты.
Первая редакция книги аж от 1972 года, насколько помню:
Глава 3. Операционная бригада
Эти исследования выявили большие индивидуальные различия в производительности между лучшими и худшими работниками, часто на порядок величин.
САКМАН, ЭРИКСОН И ГРАНТ
На встречах компьютерных специалистов можно постоянно слышать утверждения молодых менеджеров программных проектов, что им предпочтительней небольшие деятельные команды первоклассных специалистов, чем проекты, в которых участвуют сотни программистов, что подразумевает их средний уровень. И всем нам тоже.
Такое наивное представление альтернатив уходит от решения сложной задачи — как создавать большие системы в разумные сроки? Рассмотрим этот вопрос более подробно со всех сторон.
Проблема
Менеджеры программных проектов давно поняли, что хорошие и плохие программисты очень сильно различаются между собой по производительности. Однако реально измеренные величины поразительны. В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов. Правда, возможно и обратное. Полученные данные не выявили какой-либо корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)
Здравствуйте, bkat, Вы писали:
B>Еще правда в том, что великих программистов мало, B>и они хотят создавать исключительно великие программы. B>В то же время очень много разных задач, которые нужно решать сейчас, а не ждать, B>когда их решат великие программисты.
(зевает) ...А покажите мне хоть одного программиста, не считающего себя великим. Мания величия — это у нас профессиональное.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>(зевает) ...А покажите мне хоть одного программиста, не считающего себя великим. Мания величия — это у нас профессиональное.
Не знаю... Не замечал, что это профессиональное.
Ну бывает что человек неадекватно оценивает себя.
Обычно это либо начинающие, либо те, кто долго варились в собственном соку
и не имели возможность сравнить себя с другим. В целом не все так плохо.
Но это не совсем в тему топика.
Здравствуйте, fplab, Вы писали:
F>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>И по-моему он ведь прав, как вы думаете ?
сначала надо определить что такое "великая программа", потом осознать — нужны ли в посведневной жизни великие программы (ну т.е. готовы ли за них платить) — ну а потом может быть даже смысла не будет отделять великих программистов от просто страдающих манией величия.
Здравствуйте, Igor Sukhov, Вы писали:
IS>Здравствуйте, fplab, Вы писали:
F>>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>>И по-моему он ведь прав, как вы думаете ?
IS>сначала надо определить что такое "великая программа", потом осознать — нужны ли в посведневной жизни великие программы (ну т.е. готовы ли за них платить) — ну а потом может быть даже смысла не будет отделять великих программистов от просто страдающих манией величия.
А кто его знает, что такое великая программа
Первый UNIX написанный Деннисом Ритчи — это великая программа или нет ? Всего-то семь килобайт откомпилированного кода, но зато какая идея ! И незаметно, чтобы Ритчи страдал манией величия.
Я не случайно привел цитату именно Билла Джоя: уж он то как раз имеет право судить о том, что считать великой программой; он сам в рамках реализации UNIX Berkley (впоследствии — BSD) был ведущим разработчиком таких вещей как виртуальная память, подкачка по требованию, замещение страниц, сокеты и TCP/IP. По меньшей мере реализацию стека TCP/IP — можно считать великой программой, или нет ?
Так что мой ответ на Ваш вопрос
нужны ли в посведневной жизни великие программы
будет простым — да, нужны. И при этом за великие программы далеко не всегда обязательно надо платить.
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
...skipped...
IS>сначала надо определить что такое "великая программа", потом осознать — нужны ли в посведневной жизни великие программы (ну т.е. готовы ли за них платить) — ну а потом может быть даже смысла не будет отделять великих программистов от просто страдающих манией величия.
еще такое ощущение, что тут свое слово сказали "трудности перевода" почему great — переводить сразу так пафосно: великий? Возможны ведь варианты. Великолепный, превосходный, восхитительный, замечательный и т.п. И фраза тогда зазвучит немножко по-другому, без этого пафоса и самомнения.
Здравствуйте, ryf, Вы писали:
ryf>еще такое ощущение, что тут свое слово сказали "трудности перевода" почему great — переводить сразу так пафосно: великий? Возможны ведь варианты. Великолепный, превосходный, восхитительный, замечательный и т.п. И фраза тогда зазвучит немножко по-другому, без этого пафоса и самомнения.
Ну и что изменится если перевести так?
Правда в том, что замечательные программы создаются превосходными программистами
Здравствуйте, fplab, Вы писали:
F>Случайно "накопал" ссылку на статью в NYT где Билл Джой говорит: F>
F>"The truth is, great software comes from great programmers, not from a large number of people slaving away"
F>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>И по-моему он ведь прав, как вы думаете ?
The truth is, great buildings come from great architects...
The truth is, good car maintainance comes from good mechanics...
И так до бесконечности...
А вот например Египетские пирамиды, "large number of people were slaving away".
Но вот стоят до сих пор. Гениален был тот кто организовал этот процесс — от проектирования до института прорабства.
Так и в софте: есть программы где экономически более оправдан great programmer, а есть где вся фенечка в great architect.
Здравствуйте, c-smile, Вы писали:
CS>Так и в софте: есть программы где экономически более оправдан great programmer, а есть где вся фенечка в great architect.
При определённом уровне сложности приложения кривые ручки способны испортить любую архитектуру.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Так и в софте: есть программы где экономически более оправдан great programmer, а есть где вся фенечка в great architect.
IT>При определённом уровне сложности приложения кривые ручки способны испортить любую архитектуру.
В принципе хорошая организация процесса разработки может затруднить такую порчу.
Но тут уже в действие вступает закон больших чисел. В принципе, да, при определенном уровне затраты на например процесс code review могут нивелировать все выигрыши от нанятия толпы выпусников 3 месячных курсов.
Здравствуйте, c-smile, Вы писали:
IT>>При определённом уровне сложности приложения кривые ручки способны испортить любую архитектуру.
CS>В принципе хорошая организация процесса разработки может затруднить такую порчу.
Практически невозможно. Разве что на каждого такого девелопера нанимать по бебиситеру.
Был у меня на одном проекте в IBM в команде индус, который выполнял от силы 5% работы в команде, но производил при этом 80% багов. Был очень послушен и старателен. Тем не менее через пол года был уволен, после чего его код был переписан за три дня, сдан и забыт.
CS>Но тут уже в действие вступает закон больших чисел. В принципе, да, при определенном уровне затраты на например процесс code review могут нивелировать все выигрыши от нанятия толпы выпусников 3 месячных курсов.
С "опытными" как раз может оказаться гораздо хуже, чем с выпускниками. Чем опытнее такой девелопер, тем дальше он тебя будет посылать на code review. Если не открытым текстом "на хер", то тихий саботах обеспечен как минимум.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Но тут уже в действие вступает закон больших чисел. В принципе, да, при определенном уровне затраты на например процесс code review могут нивелировать все выигрыши от нанятия толпы выпусников 3 месячных курсов.
IT>С "опытными" как раз может оказаться гораздо хуже, чем с выпускниками. Чем опытнее такой девелопер, тем дальше он тебя будет посылать на code review. Если не открытым текстом "на хер", то тихий саботах обеспечен как минимум.
Может под опытом тут подразумевается в основном лишь стаж? Потому как, на мой взгляд, действительно стоящий специалист просто обязан нормально воспринимать конструктивную критику.
Здравствуйте, fplab, Вы писали:
F>Случайно "накопал" ссылку на статью в NYT где Билл Джой говорит: F>
F>"The truth is, great software comes from great programmers, not from a large number of people slaving away"
F>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>И по-моему он ведь прав, как вы думаете ?
Однако все зависит от понимания слова ВЕЛИКИЙ... ВЕЛИКИЕ — по объему- программы как раз создаются толпой народа, вкалывающих до усеру...
ОС/360, например... Windows...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Однако все зависит от понимания слова ВЕЛИКИЙ... ВЕЛИКИЕ — по объему- программы как раз создаются толпой народа, вкалывающих до усеру... LVV>ОС/360, например... Windows... LVV>
Нет, это БОЛЬШИЕ программы. Проблемма в том, что именно БОЛЬШИЕ программы приносят БОЛЬШИЕ бабки.
Здравствуйте, LaptevVV, Вы писали:
LVV>Однако все зависит от понимания слова ВЕЛИКИЙ... ВЕЛИКИЕ — по объему- программы как раз создаются толпой народа, вкалывающих до усеру...
Но в целом дизайнятся-то они единицами.
К>Может под опытом тут подразумевается в основном лишь стаж? Потому как, на мой взгляд, действительно стоящий специалист просто обязан нормально воспринимать конструктивную критику.
Не, тут вопрос сугубо в адекватности человека. ИМХО, ни стаж ни опыт тут ни при чём.
Здравствуйте, Left2, Вы писали:
К>>Может под опытом тут подразумевается в основном лишь стаж? Потому как, на мой взгляд, действительно стоящий специалист просто обязан нормально воспринимать конструктивную критику. L>Не, тут вопрос сугубо в адекватности человека. ИМХО, ни стаж ни опыт тут ни при чём.
Дак я о том и говорю, читай "стоящий" == адекватный
Здравствуйте, Курилка, Вы писали:
К>Дак я о том и говорю, читай "стоящий" == адекватный
Талантливые люди вроде бы наоборот больше склонны к эмоциональности, всевозможной мнительности, обидам и т.п. У меня есть человек, на которого приходится тратить свое личное время, дабы ублажить некоторый его эмоциональный мандраж в стиле "работаю я много, а меня никто не ценит и не любит"... но зато потом, будучи ободренным таким легким поглаживанием, он осиливает изрядный воз работы, который не по силам остальным не столь эмоциональным сотрудникам. Не скажу, что он талант, но работает намного лучше остальных... хоть и отнимает мое время.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
К>>Дак я о том и говорю, читай "стоящий" == адекватный R>Талантливые люди вроде бы наоборот больше склонны к эмоциональности, всевозможной мнительности, обидам и т.п. У меня есть человек, на которого приходится тратить свое личное время, дабы ублажить некоторый его эмоциональный мандраж в стиле "работаю я много, а меня никто не ценит и не любит"... но зато потом, будучи ободренным таким легким поглаживанием, он осиливает изрядный воз работы, который не по силам остальным не столь эмоциональным сотрудникам. Не скажу, что он талант, но работает намного лучше остальных... хоть и отнимает мое время.
Однозначной зависимости я бы тут не проводил. Может быть в сфере гуманитарных знаний это бывает чаще, но вот для чётких наук (надеюсь всёж туда мы записываем computer sciences?) способность воспринимать конструктивную критику есть основа научного подхода. А всяких обидчивых и т.п. хватает и среди не особо талантливых..
Здравствуйте, Курилка, Вы писали:
IT>>С "опытными" как раз может оказаться гораздо хуже, чем с выпускниками. Чем опытнее такой девелопер, тем дальше он тебя будет посылать на code review. Если не открытым текстом "на хер", то тихий саботах обеспечен как минимум.
К>Может под опытом тут подразумевается в основном лишь стаж?
Именно поэтому я и взял слово опытный в кавычки.
К>Потому как, на мой взгляд, действительно стоящий специалист просто обязан нормально воспринимать конструктивную критику.
Должен. Но с другой стороны как отличить критику от заблуждения. Люди часто отстаивают своё мнение элементарно чего-то не понимая или заблуждаясь. Это касается и тех кто критикует и тех кого критикуют.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
К>>Дак я о том и говорю, читай "стоящий" == адекватный R>Талантливые люди вроде бы наоборот больше склонны к эмоциональности, всевозможной мнительности, обидам и т.п. У меня есть человек, на которого приходится тратить свое личное время, дабы ублажить некоторый его эмоциональный мандраж в стиле "работаю я много, а меня никто не ценит и не любит"... но зато потом, будучи ободренным таким легким поглаживанием, он осиливает изрядный воз работы, который не по силам остальным не столь эмоциональным сотрудникам. Не скажу, что он талант, но работает намного лучше остальных... хоть и отнимает мое время.
Ну дык: management — есть создание системы мотиваций сотрудникам. Кому-то нужно поглаживание, кому медали какие...
F>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>И по-моему он ведь прав, как вы думаете ?
Все может быть.
А великие деньги часто зарабатывают как раз корпорации с толпой народа... Всякие Infosys...
Здравствуйте, Left2, Вы писали:
L>... а кому и волшебный пендаль
А нафига держать тех, кому нужен "волшебный пендаль"?
Хотя, если начальник испытывает удовольствие, раздавая пендали,
а у работника от этого повышается мотивация, то да,
такая связка будет работать
B>А нафига держать тех, кому нужен "волшебный пендаль"?
Дело в том что есть такие люди — грамотные технические специалисты, но при этом без "пендалей" работающие очччень неэффективно. Опять же, вне зависимости от профессии
B>Хотя, если начальник испытывает удовольствие, раздавая пендали, B>а у работника от этого повышается мотивация, то да, B>такая связка будет работать
Ну зачем всё сразу сводить к садо-мазо составляющей Прям фрейдизм какой-то...
Здравствуйте, fplab, Вы писали:
F>Случайно "накопал" ссылку на статью в NYT где Билл Джой говорит: F>
F>"The truth is, great software comes from great programmers, not from a large number of people slaving away"
F>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>И по-моему он ведь прав, как вы думаете ?
Фраза вырвана из контекста и поэтому ее обсуждение пошло не в ту степь. В статье обсуждается пришествие OpenSource в мейнстрим и последствия этого. А слова Джоя относятся к одному из мифов вокруг OpenSource, что мол достаточно любой проект сделать открытым и тут же набегут сотни/тысячи фанатичных разработчиков и все быстренько и качественно сделают. Ага На практике это совершенно не так и в любом OpenSource проекте есть всего лишь несколько ключевых разработчиков, от которых реально что-то зависит. Остальные что-то делают по мере сил и вообще приносят огромную пользу, но качество проекта зависит от степени толковости ключевых участников проекта (тех самых lone craftman, которых противопоставляют collaborator-ам). И здесь OpenSource проекты не сильно-то и отличаются от закрытого ПО, имхо.
Вот об этом-то Джой и говорит, что без толковых исполнителей нормального результата не будет. И OpenSource не дает какой-нибудь новой надежды производителям ПО -- мол, если вам не удалось подобрать нормальную команду для proprietary проекта, то нефиг надеятся на то, что вы сделаете это для OpenSource проекта. Но будучи вырванными из контекста его слова звучат так, что мол есть супер-пупер программисты, которые делаю супер-пупер ПО. А посему нужно понять, что такое супер-пупер, и кого же можно называть супер-пупер, если не себя самого... Ну и дальше обычные рассуждения про элиту/быдло, раздавание пендалей, отнимание пряников и разрывание на британский флаг
А правда в том, что если работаешь программистом, то вкалывание до усеру -- это одна из специфических черт профессии. Вне зависимости от размера great.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, c-smile, Вы писали:
CS>А вот например Египетские пирамиды, "large number of people were slaving away". CS>Но вот стоят до сих пор. Гениален был тот кто организовал этот процесс — от проектирования до института прорабства.
Ну это обычная путаница. Ближайшей аналогией к разработке программы будет как раз построение схемы организации труда и чертежей Пирамиды, а не таскание камней. В этом и принципиальная разница между софтом и промсборкой автомобилей на конвейере.
Человек может быть ахрененно великий, но таскать в одиночку 20титонные камни все равно не сможет.
Кстати, по современным исследованиям утверждается, что при постройке Пирамид активно применялись высококлассные специалисты. Все работы кроме "тащи туда, поднимай сюда" — а это много что — камнетесы, прорабы, снабженцы, инженеры, художники, архитекторы, руководители и проч — очень хорошо оплачивались. Плюс любое участие в строительстве Пирамид было очень почетно.
Так что организовано все было черезвычайно хорошо, в результате чего такое титаническое сооружение было построено не таким уж большим количеством народу.
Здравствуйте, eao197, Вы писали:
E>А правда в том, что если работаешь программистом, то вкалывание до усеру -- это одна из специфических черт профессии. Вне зависимости от размера great.
Правда в том, что вкалывание до усеру в программировании далеко не является определяющим фактором успеха. Скорее даже наоборот.
Если нам не помогут, то мы тоже никого не пощадим.
Вот это: E>А посему нужно понять, что такое супер-пупер, и кого же можно называть супер-пупер, если не себя самого...
плюс это: E>А правда в том, что если работаешь программистом, то вкалывание до усеру -- это одна из специфических черт профессии. Вне зависимости от размера great.
звучит вместе несколько забавно.
Так-то в любом деле надо работать... что такого исключительного в программистах?
PS И по-моему, IT прав: до усеру работает тот, кто плохо умеет работать так, чтобы не работать до усеру, при этом делая столько же или даже больше (обычно именно второе). Если программист не может автоматизировать (облегчить, упросить и etc) свой собственный труд, то, чего уж говорить о написанных им программах.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, eao197, Вы писали:
R>Вот это: E>>А посему нужно понять, что такое супер-пупер, и кого же можно называть супер-пупер, если не себя самого... R>плюс это: E>>А правда в том, что если работаешь программистом, то вкалывание до усеру -- это одна из специфических черт профессии. Вне зависимости от размера great. R>звучит вместе несколько забавно.
Похоже, что я пропустил одно ключевое слово: "эпизодически". Я подразумевал "эпизодическое вкалывание до усеру".
R>Так-то в любом деле надо работать... что такого исключительного в программистах?
Хотя бы то, что программирование -- это способ перевода своих идей в жесткие программные инструкции. И этот процесс является неформальным и недетерминированным. Выше был наглядный пример -- я забыл написать одно важное слово в предложении. Зато смысл написанного сильно поменялся. Тоже самое происходит и в программировании -- один хочет чего-то, второй это не очень точно записывает, третий не точно реализует, четвертый не очень качественно тестирует, пятый документирует лишь то, что сам смог понять -- и все это повторяется когда первый получает вроде-бы то, что сам хотел.
Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики. Но это проблемы представителей тех профессий. Программистам же нужно знать, что переодические переработки -- это следствие особенностей такого процесса, как программирование.
R>PS И по-моему, IT прав: до усеру работает тот, кто плохо умеет работать так, чтобы не работать до усеру, при этом делая столько же или даже больше (обычно именно второе). Если программист не может автоматизировать (облегчить, упросить и etc) свой собственный труд, то, чего уж говорить о написанных им программах.
Да, конечно. И мы все здесь такие классные программисты, что и собственный труд автоматизируем, и работаем с 9 до 18, и качественное ПО выпускаем. Ага
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, fplab, Вы писали:
F>И по-моему он ведь прав, как вы думаете ?
Великие программы — создаются великими мыслителями. Главное — чтобы была мысль великая и могучая. А реализацию под мысль организовать — дело техники.
Здравствуйте, fplab, Вы писали:
F>Здравствуйте, Igor Sukhov, Вы писали:
IS>>Здравствуйте, fplab, Вы писали:
F>>>что (несколько вольно) можно перевести как "Правда в том, что великие программы создаются великими программистами, а не толпой народа, вкалывающего до усёру". F>>>И по-моему он ведь прав, как вы думаете ?
IS>>сначала надо определить что такое "великая программа", потом осознать — нужны ли в посведневной жизни великие программы (ну т.е. готовы ли за них платить) — ну а потом может быть даже смысла не будет отделять великих программистов от просто страдающих манией величия. F>А кто его знает, что такое великая программа F>Первый UNIX написанный Деннисом Ритчи — это великая программа или нет ? Всего-то семь килобайт откомпилированного кода, но зато какая идея ! И незаметно, чтобы Ритчи страдал манией величия. F>Я не случайно привел цитату именно Билла Джоя: уж он то как раз имеет право судить о том, что считать великой программой; он сам в рамках реализации UNIX Berkley (впоследствии — BSD) был ведущим разработчиком таких вещей как виртуальная память, подкачка по требованию, замещение страниц, сокеты и TCP/IP. По меньшей мере реализацию стека TCP/IP — можно считать великой программой, или нет ?
Не согласен с вами. TCP/IP — это всего лишь реализация стека протоколов,
как и, например, IPX/SPX.
Сам стек TCP/IP вырос из модели OSI — просто и со вкусом.
В мире коммуникаций такие стеки не новость.
Вы наверное писали не о "реализации стека", а о его современной значимости,
но тут говорить о каком-либо величии не приходится. С ним проблемы, с ним небезопасно и он везде.
F>Так что мой ответ на Ваш вопрос F>
F>нужны ли в посведневной жизни великие программы
F>будет простым — да, нужны. И при этом за великие программы далеко не всегда обязательно надо платить.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, fplab, Вы писали:
F>>И по-моему он ведь прав, как вы думаете ? GZ>Великие программы — создаются великими мыслителями. Главное — чтобы была мысль великая и могучая. А реализацию под мысль организовать — дело техники.
Согласен
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, Deff, Вы писали: D>Не согласен с вами. TCP/IP — это всего лишь реализация стека протоколов, D>как и, например, IPX/SPX. D>Сам стек TCP/IP вырос из модели OSI — просто и со вкусом.
Да ну, правда што ли? И какая же часть модели Изи и Оси описывает, к примеру, использование протоколом нижнего уровня протокола верхнего уровня? См. ICMP vs IP. D>В мире коммуникаций такие стеки не новость.
Наверняка. Их, наверное, миллионы. А вот почему распространился повсеместно именно TCP/IP? D>Вы наверное писали не о "реализации стека", а о его современной значимости,
А я думаю — как раз о самом стеке. Ну и его реализации, конечно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Deff, Вы писали: D>>Не согласен с вами. TCP/IP — это всего лишь реализация стека протоколов, D>>как и, например, IPX/SPX. D>>Сам стек TCP/IP вырос из модели OSI — просто и со вкусом. S>Да ну, правда што ли? И какая же часть модели Изи и Оси описывает, к примеру, использование протоколом нижнего уровня протокола верхнего уровня? См. ICMP vs IP.
Не могу прокомментировать, т.к. ваша мысль мне непонятна.
Концептуальность модели OSI просто не позволяет искать в ней описания тех или иных
аспектов реализации каких-либо стеков (т.к. последнее просто набор частностей).
Однако, это не умаляет её значимости.
Главное — что в основе лежит красивая и действенная идея.
D>>В мире коммуникаций такие стеки не новость. S>Наверняка. Их, наверное, миллионы. А вот почему распространился повсеместно именно TCP/IP?
TCP/IP распространен, т.к. речь идет о фактическом стандарте.
Как он дорос в стандарта?
..может потому, что его создание было инициировано минобороны США?
Или потому, что был учтен опыт arpanet и других сетей, реализована поддержка популярных протоколов,
совместимость с различными стандартами канального уровня?
А может дело в unix?
Я бы сказал так: по историческим причинам, да и лучшего не было.
D>>Вы наверное писали не о "реализации стека", а о его современной значимости, S>А я думаю — как раз о самом стеке. Ну и его реализации, конечно.
Это разделение я и хотел подчеркнуть.
Точнее: идея, реализация, значимость.
Здравствуйте, Left2, Вы писали:
B>>А нафига держать тех, кому нужен "волшебный пендаль"? L>Дело в том что есть такие люди — грамотные технические специалисты, но при этом без "пендалей" работающие очччень неэффективно.
В условиях рыночной экономики у каждого наемного работника есть глобальный пендаль, который называется "нет денег". По эффективности этот пендаль на голову превосходит все, что может измыслить начальство, оставаясь в рамках закона. Поэтому раздача начальством пендалей ни к чему, кроме ухудшения отношений, не приведет.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, rsn81, Вы писали:
LVV>>Однако все зависит от понимания слова ВЕЛИКИЙ... ВЕЛИКИЕ — по объему- программы как раз создаются толпой народа, вкалывающих до усеру... R>Но в целом дизайнятся-то они единицами.
Но для этих единиц достаточно быть good enough, чтобы проект был успешным, а не великими.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, eao197, Вы писали:
E>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
А с чего ты взял, что авралы это часть профессиональной специфики программирования?
E>Программистам же нужно знать, что переодические переработки -- это следствие особенностей такого процесса, как программирование.
Это следствие особенностей безруких менеджеров.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
E>>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
AVK>А с чего ты взял, что авралы это часть профессиональной специфики программирования?
Собственный опыт, опыт моих знакомых.
Наличие книги "Путь камикадзе" и самого понятия "безнадежный проект".
E>>Программистам же нужно знать, что переодические переработки -- это следствие особенностей такого процесса, как программирование.
AVK>Это следствие особенностей безруких менеджеров.
..., бесталанных программистов и плохого инструментария.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Собственный опыт, опыт моих знакомых.
Твоего личного опыта недостаточно, чтобы обобщать подобным образом. Мой опыт, к примеру, говорит о том, что за последние 5 лет у нас не было ни одного аврала.
E>Наличие книги "Путь камикадзе" и самого понятия "безнадежный проект".
Я что то не припоминаю, чтобы в ней говорилось о неизбежности авралов.
AVK>>Это следствие особенностей безруких менеджеров.
E>..., бесталанных программистов и плохого инструментария.
Нет, только безруких менеджеров.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Но для этих единиц достаточно быть good enough, чтобы проект был успешным, а не великими.
Осталось только понять, что все в этой теме понимают под "вкалывать до усеру".
Здравствуйте, AndrewVK, Вы писали:
E>>Собственный опыт, опыт моих знакомых.
AVK>Твоего личного опыта недостаточно, чтобы обобщать подобным образом.
Моего личного опыта достаточно для того, что бы я сам так считал. И высказывал то, в чем сам убежден. А данная убежденность происходит из того, что 13 лет работы программистом я не видел ни одного критически важного для организаций в которых мне довелось работать проекта, который обходился без каких-либо форм авралов и сверхурочной работы.
AVK>Мой опыт, к примеру, говорит о том, что за последние 5 лет у нас не было ни одного аврала.
Этого достаточно, чтобы ты не верил мне. Но твоего опыта не достаточно, чтобы переубедить меня.
E>>Наличие книги "Путь камикадзе" и самого понятия "безнадежный проект".
AVK>Я что то не припоминаю, чтобы в ней говорилось о неизбежности авралов.
В ней говорилось, что один из типов безнадежных проектов -- это проекты, где сроки сдачи проектов на 50% меньше, чем это необходимо. Реализация такого проекта -- это сам по себе один сплошной аврал.
AVK>>>Это следствие особенностей безруких менеджеров.
E>>..., бесталанных программистов и плохого инструментария.
AVK>Нет, только безруких менеджеров.
Я эти два выходных провожу на работе в попытке исправить допущенную мной при проектировании ошибку чтобы уложиться в отведенное мне время. Здесь я сам себе злобный буратино и менеджеры вовсе не причем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, fplab, Вы писали:
F>>И по-моему он ведь прав, как вы думаете ? GZ>Великие программы — создаются великими мыслителями. Главное — чтобы была мысль великая и могучая. А реализацию под мысль организовать — дело техники.
К счастью или к сожелению, весь процесс реализации распадаются на под задачи, каждая из которых, требует небольшого, но архитектурного решения, где требуется незаурядный мозг. Изначально идея проекта может быть очень классная, но чтобы ее осущетсвить нужны таланты.
Здравствуйте, eao197, Вы писали:
E>Моего личного опыта достаточно для того, что бы я сам так считал. И высказывал то, в чем сам убежден.
Ну это да, сам ты имеешь полное право быть убежденным в чем угодно, хоть в том, что земля плоская.
E> А данная убежденность происходит из того, что 13 лет работы программистом я не видел ни одного критически важного для организаций в которых мне довелось работать проекта, который обходился без каких-либо форм авралов и сверхурочной работы.
А сколько организаций в твоей выборке?
AVK>>Я что то не припоминаю, чтобы в ней говорилось о неизбежности авралов.
E>В ней говорилось, что один из типов безнадежных проектов -- это проекты, где сроки сдачи проектов на 50% меньше, чем это необходимо. Реализация такого проекта -- это сам по себе один сплошной аврал.
И что? Это как то свидетельствет о том что авралы — неизбежное явление?
E>>>..., бесталанных программистов и плохого инструментария.
AVK>>Нет, только безруких менеджеров.
E>Я эти два выходных провожу на работе
Поздравляю.
E> в попытке исправить допущенную мной при проектировании ошибку чтобы уложиться в отведенное мне время.
А время кто тебе отводил. И на основании чего? И как эти два выходных оплачиваются?
E> Здесь я сам себе злобный буратино и менеджеры вовсе не причем.
Т.е., чтобы не работать в выходные, проектировщик обязан вообще не допускать ошибок, так?
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Моего личного опыта достаточно для того, что бы я сам так считал. И высказывал то, в чем сам убежден.
AVK>Ну это да, сам ты имеешь полное право быть убежденным в чем угодно, хоть в том, что земля плоская.
Для того, чтобы доказать, что земля не плоская, нужно привести объективные доказательства.
Если ты убежден, что я не прав насчет авралов в программировании -- объективные доказательства приведи, пожалуйста.
E>> А данная убежденность происходит из того, что 13 лет работы программистом я не видел ни одного критически важного для организаций в которых мне довелось работать проекта, который обходился без каких-либо форм авралов и сверхурочной работы.
AVK>А сколько организаций в твоей выборке?
В четырех я сам работал. Еще о 3-4-х я знаю со слов знакомых. Еще о некоторых читал в книгах, блогах, форумах.
AVK>>>Я что то не припоминаю, чтобы в ней говорилось о неизбежности авралов.
E>>В ней говорилось, что один из типов безнадежных проектов -- это проекты, где сроки сдачи проектов на 50% меньше, чем это необходимо. Реализация такого проекта -- это сам по себе один сплошной аврал.
AVK>И что? Это как то свидетельствет о том что авралы — неизбежное явление?
Это доказательство того, что авралы в программировании случаются. Причем являются следствием специфики самого занятия программирования. Т.е. программирование, в отличии от, например, биологии, позволяет кому-то думать, что 9-ти месячную работу можно сделать за 1 месяц. И сделать, что характерно.
E>> в попытке исправить допущенную мной при проектировании ошибку чтобы уложиться в отведенное мне время.
AVK>А время кто тебе отводил. И на основании чего?
Я сам себе отводил. На основании опыта решения подобных задач в прошлом.
E>> Здесь я сам себе злобный буратино и менеджеры вовсе не причем.
AVK>Т.е., чтобы не работать в выходные, проектировщик обязан вообще не допускать ошибок, так?
Для того, чтобы не работать в выходные слишком многие не должны допускать ошибок. И менеджер, и проектировщик, и программист.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Ну это да, сам ты имеешь полное право быть убежденным в чем угодно, хоть в том, что земля плоская.
E>Для того, чтобы доказать, что земля не плоская, нужно привести объективные доказательства.Если ты убежден, что я не прав насчет авралов в программировании -- объективные доказательства приведи, пожалуйста.
Не, брателлас, это ты утверждение сделал о том, что профессия пограммиста подразумевает авралы, на тебе и бремя доказательства.
AVK>>И что? Это как то свидетельствет о том что авралы — неизбежное явление?
E>Это доказательство того, что авралы в программировании случаются.
А с этим никто и не спорил. Но между "случаются" и "являются частью профессиональной специфики" есть разительная разница, не находишь?
E> Причем являются следствием специфики самого занятия программирования. Т.е. программирование, в отличии от, например, биологии, позволяет кому-то думать, что 9-ти месячную работу можно сделать за 1 месяц. И сделать, что характерно.
Это все по прежнему голословные утверждения.
AVK>>А время кто тебе отводил. И на основании чего?
E>Я сам себе отводил. На основании опыта решения подобных задач в прошлом.
А, ну тогда ты ССЗБ.
AVK>>Т.е., чтобы не работать в выходные, проектировщик обязан вообще не допускать ошибок, так?
E>Для того, чтобы не работать в выходные слишком многие не должны допускать ошибок. И менеджер, и проектировщик, и программист.
Поздравляю. Однако почему тогда на всех местах, где я работал, я обходился без авралов? Ошибки у меня не той системы?
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Ну это да, сам ты имеешь полное право быть убежденным в чем угодно, хоть в том, что земля плоская.
E>>Для того, чтобы доказать, что земля не плоская, нужно привести объективные доказательства.Если ты убежден, что я не прав насчет авралов в программировании -- объективные доказательства приведи, пожалуйста.
AVK>Не, брателлас, это ты утверждение сделал о том, что профессия пограммиста подразумевает авралы, на тебе и бремя доказательства.
Еще раз -- на основании моего опыта выходит, что профессия программиста подразумевает авралы. Ты с этим не согласен -- доказывай обратное.
AVK>>>И что? Это как то свидетельствет о том что авралы — неизбежное явление?
E>>Это доказательство того, что авралы в программировании случаются.
AVK>А с этим никто и не спорил. Но между "случаются" и "являются частью профессиональной специфики" есть разительная разница, не находишь?
Не нахожу, поскольку по мне "случаются" -- это следствие "профессиональной специфики".
E>> Причем являются следствием специфики самого занятия программирования. Т.е. программирование, в отличии от, например, биологии, позволяет кому-то думать, что 9-ти месячную работу можно сделать за 1 месяц. И сделать, что характерно.
AVK>Это все по прежнему голословные утверждения.
1 месяц вместо 9-ти -- это гипербола.
Но вот ускорить рождение клона овечки Долли биологи не могли. А в программировании случаи, когда разработчиков вынуждают обстоятельства делать проекты быстрее, чем это должно было бы быть -- сплошь и рядом.
У меня в 2003-м был случай -- в четверг на наше руководство вышел заказчик с просьбой выполнить в буквальном смысле "горящий" заказ -- небольшую коммуникационную программу, которую нужно было запустить в боевую эксплуатацию на следующей неделе в среду. Т.е. во вторник она должна была быть полностью протестирована заказчиком, а в понедельник -- нами самими. В пятницу меня вызвали в Москву для решения этой проблемы. Выходные ушли на разработку, в понедельник к вечеру все было готово и протестировано, во вторник проверен весь комплекс, в среду все заработало. А по хорошему, там было на неделю спокойной размеренной работы с 9 до 18.
Сильно сомневаюсь, что в биологии, например, можно бы вырастить какую-нибудь грибковую культуру к определенной дате начхав на объективную скорость роста этой культуры.
AVK>>>Т.е., чтобы не работать в выходные, проектировщик обязан вообще не допускать ошибок, так?
E>>Для того, чтобы не работать в выходные слишком многие не должны допускать ошибок. И менеджер, и проектировщик, и программист.
AVK>Поздравляю. Однако почему тогда на всех местах, где я работал, я обходился без авралов? Ошибки у меня не той системы?
Может тебе везло? Может ты в стартапах не работал? Тебе виднее.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Не, брателлас, это ты утверждение сделал о том, что профессия пограммиста подразумевает авралы, на тебе и бремя доказательства.
E>Еще раз -- на основании моего опыта выходит, что профессия программиста подразумевает авралы. Ты с этим не согласен -- доказывай обратное.
Что то я не понял. Почему ты считаешь, что ты ничего доказывать не обязан, а я обязан?
E>Но вот ускорить рождение клона овечки Долли биологи не могли.
Демагогия — доказательство по аналогии.
E> А в программировании случаи, когда разработчиков вынуждают обстоятельства делать проекты быстрее, чем это должно было бы быть -- сплошь и рядом.
И при чем тут программирование? Может это проблема разработчиков, страдающих излишним оптимизмом при оценке сроков?
E>У меня в 2003-м был случай -- в четверг на наше руководство вышел заказчик с просьбой выполнить в буквальном смысле "горящий" заказ -- небольшую коммуникационную программу, которую нужно было запустить в боевую эксплуатацию на следующей неделе в среду. Т.е. во вторник она должна была быть полностью протестирована заказчиком, а в понедельник -- нами самими.
Ну, если заказчик платит за срочность, то тут надо просто решить, что для тебя важнее — переработка или дополнительные деньги. Но, опять же, никакой специфики тут нет.
E> В пятницу меня вызвали в Москву для решения этой проблемы.
Т.е, когда заключали договор с заказчиком, тебя даже не спросили, готов ли ты работать в выходные?
E>Сильно сомневаюсь, что в биологии, например, можно бы вырастить какую-нибудь грибковую культуру к определенной дате начхав на объективную скорость роста этой культуры.
Зато в биологии вполне можно увеличить количество проб, культур etc, чем ускорить полную программу анализа. Да и не думаю, что ты хоть что то понимаешь в биологии, чтобы рассуждать об этом.
AVK>>Поздравляю. Однако почему тогда на всех местах, где я работал, я обходился без авралов? Ошибки у меня не той системы?
E> Может тебе везло?
Все время везти не может.
E> Может ты в стартапах не работал?
А ты работаешь в стартапе?
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Deff, Вы писали:
S>>Да ну, правда што ли? И какая же часть модели Изи и Оси описывает, к примеру, использование протоколом нижнего уровня протокола верхнего уровня? См. ICMP vs IP. D>Не могу прокомментировать, т.к. ваша мысль мне непонятна.
Поясняю мысль: TCP/IP не вырос из модели ISO/OSI. Он ей противоречит. D>Концептуальность модели OSI просто не позволяет искать в ней описания тех или иных D>аспектов реализации каких-либо стеков (т.к. последнее просто набор частностей).
Вполне себе позволяет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Не, брателлас, это ты утверждение сделал о том, что профессия пограммиста подразумевает авралы, на тебе и бремя доказательства.
E>>Еще раз -- на основании моего опыта выходит, что профессия программиста подразумевает авралы. Ты с этим не согласен -- доказывай обратное.
AVK>Что то я не понял. Почему ты считаешь, что ты ничего доказывать не обязан, а я обязан?
В моей карьере периодические авралы случаются постоянно. Это факт.
Ряд авралов был следствием специфических черт программирования. Это моя гипотеза, возникшая на основе фактов (коих я могу привести множество).
Доказать эту свою гипотезу объективно я не могу. Но и ты не можешь ее опровергнуть без объективных доказательств. Так что, если ты настаиваешь на том, что я не прав -- приводи объективные доказательства.
Поскольку все это напоминает мне теорему Пифагора: если бы я сказал, что по моему опыту квадрат гипотенузы не равен сумме квадратов катетов, то ты бы мог привести в качестве опровержения моих слов доказательство теоремы Пифагора. Все просто -- если есть объективное доказательство моей неправоты -- зачем же его скрывать?
E>>Но вот ускорить рождение клона овечки Долли биологи не могли.
AVK>Демагогия — доказательство по аналогии.
Ну вот и докатились. Но, надо признать, что долго держались в этот раз. Хотя более привычно выглядит формулировка:
Доказательство по аналогии -- это демагогия.
Однако, в этой связи вопрос -- как можно доказывать специфичность такого занятия, как программирование, не проводя аналогий с другими предметными областями?
E>> А в программировании случаи, когда разработчиков вынуждают обстоятельства делать проекты быстрее, чем это должно было бы быть -- сплошь и рядом.
AVK>И при чем тут программирование? Может это проблема разработчиков, страдающих излишним оптимизмом при оценке сроков?
При том, что программирование целиком зависит от оптимизма/пессимизма разработчиков. И не только разработчиков.
E>>У меня в 2003-м был случай -- в четверг на наше руководство вышел заказчик с просьбой выполнить в буквальном смысле "горящий" заказ -- небольшую коммуникационную программу, которую нужно было запустить в боевую эксплуатацию на следующей неделе в среду. Т.е. во вторник она должна была быть полностью протестирована заказчиком, а в понедельник -- нами самими.
AVK>Ну, если заказчик платит за срочность, то тут надо просто решить, что для тебя важнее — переработка или дополнительные деньги. Но, опять же, никакой специфики тут нет.
Ну вот он -- ключевой момент. Ты считаешь, что впихивание гораздо большего объема работ в сжатые сроки не является специфической чертой программирования. Я здесь с тобой не согласен, по-моему, это как раз типично для программирования. А причин, по которым работать приходится гораздо больше и/или напряженнее в программировании достаточно:
— сложность выуживания из заказчика конкретных пожеланий и спецификаций;
— излишний оптимизм менеджеров, проектировщиков, разработчиков;
— сложность перевода ментальных моделей, существующих в головах проектировщиков/разработчиков, в программный код;
— баги, допущенные как из-за недопонимания предметной области, так и из-за элементарных опечаток;
— человеческий фактор (разные уровни подготовки программистов, разные уровни производительности одного и того же программиста в зависимости от ряда факторов (семейные проблемы, увлеченность задачей, взаимоотношения в коллективе, приближение/отдаление очередного отпуска,...), отпуска, больничные, увольнения, ...);
— постоянный прогресс в инструментах (языки программирования, технологии, библиотеки и фреймворки);
— и, наверняка, что-то еще
E>> В пятницу меня вызвали в Москву для решения этой проблемы.
AVK>Т.е, когда заключали договор с заказчиком, тебя даже не спросили, готов ли ты работать в выходные?
У меня спросили, смогу ли я сделать эту программу вовремя и я прекрасно понимал, что придется работать в выходные. И договор с заказчиком был заключен после моего утвердительного ответа.
AVK>>>Поздравляю. Однако почему тогда на всех местах, где я работал, я обходился без авралов? Ошибки у меня не той системы?
E>> Может тебе везло?
AVK>Все время везти не может.
Если речь идет о последних пяти годах -- так это даже и не срок.
E>> Может ты в стартапах не работал?
AVK>А ты работаешь в стартапе?
Ну еще пару лет назад мы были типичным стартапом.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, shrecher, Вы писали:
S>К счастью или к сожелению, весь процесс реализации распадаются на под задачи, каждая из которых, требует небольшого, но архитектурного решения, где требуется незаурядный мозг. Изначально идея проекта может быть очень классная, но чтобы ее осущетсвить нужны таланты.
По опыту скажу так. Не столь важно что программа глючная, тормозная и т.д. Важна сама идея, и умение ее продать. И если ты не крутой монополист, то максимум чего произойдет — то что конкуренты напишут то же самое и пользователи постепенно уйдут к ним. Все продукты отличаются своими недостатками. Выигрывают те продукты, которые лучше умеют продавать.
ЗЫ. Другое дело что ты, как разработчик, не получишь морального удовлетворения от хорошо сделанного дела. Но это, к сожалению, другая песня.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, shrecher, Вы писали:
S>>К счастью или к сожелению, весь процесс реализации распадаются на под задачи, каждая из которых, требует небольшого, но архитектурного решения, где требуется незаурядный мозг. Изначально идея проекта может быть очень классная, но чтобы ее осущетсвить нужны таланты. GZ>По опыту скажу так. Не столь важно что программа глючная, тормозная и т.д. Важна сама идея, и умение ее продать. И если ты не крутой монополист, то максимум чего произойдет — то что конкуренты напишут то же самое и пользователи постепенно уйдут к ним. Все продукты отличаются своими недостатками. Выигрывают те продукты, которые лучше умеют продавать.
Не все программы, вообще-то говоря, продаются. К достижениям упомянутого здесь Билла Джоя относится и редактор vi, который появился в 1976-м году и до сих пор актуален (правда благодоря силам другого выдающегося разработчика, Брама Муленара, поддерживающего vim). Аналогично и с emacs, появившегося благодоря таланту Столмана. Сейчас ни vi, ни vim, ни emacs никем не продаются, но тем не менее, остаются весьма восстребованными. И являются, имхо, как раз хорошим примером классного ПО, разработанного классными разработчиками.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Что то я не понял. Почему ты считаешь, что ты ничего доказывать не обязан, а я обязан?
E>В моей карьере периодические авралы случаются постоянно. Это факт.
А я про твою карьеру и не говорю.
E>Доказать эту свою гипотезу объективно я не могу.
На этом можно закончить.
E> Но и ты не можешь ее опровергнуть без объективных доказательств.
А я и не должен ее опровергать. Впрочем, аргументы твоего уровня у меня тоже есть — последние 5 лет у меня не было ни одного аврала. Причем, суть твоей гипотезы такова, что сколь угодно большое количество положительных примеров, если это количество существенно меньше общего их числа, твою гипотезу не доказывают, зато единственный отрицательный пример спогсобен ее опровергнуть.
E>>>Но вот ускорить рождение клона овечки Долли биологи не могли.
AVK>>Демагогия — доказательство по аналогии.
E>Ну вот и докатились. Но, надо признать, что долго держались в этот раз.
Все вопросы задавай себе.
E>Однако, в этой связи вопрос -- как можно доказывать специфичность такого занятия, как программирование, не проводя аналогий с другими предметными областями?
Аналогии это не плохое доказательство, они просто не являются доказательством.
AVK>>И при чем тут программирование? Может это проблема разработчиков, страдающих излишним оптимизмом при оценке сроков?
E>При том, что программирование целиком зависит от оптимизма/пессимизма разработчиков.
Ужас.
E>Ну вот он -- ключевой момент. Ты считаешь, что впихивание гораздо большего объема работ в сжатые сроки не является специфической чертой программирования.
Да.
E> Я здесь с тобой не согласен, по-моему, это как раз типично для программирования.
Доказательства в студию.
E> А причин, по которым работать приходится гораздо больше и/или напряженнее в программировании достаточно: E>- сложность выуживания из заказчика конкретных пожеланий и спецификаций;
Никоим образом не доказывает необходимость авралов.
E>- излишний оптимизм менеджеров, проектировщиков, разработчиков;
Никоим образом не доказывает необходимость авралов. И вообще это неправда. Все зависит от конкретных команд.
E>- сложность перевода ментальных моделей, существующих в головах проектировщиков/разработчиков, в программный код;
Никоим образом не доказывает необходимость авралов.
E>- баги, допущенные как из-за недопонимания предметной области, так и из-за элементарных опечаток;
Никоим образом не доказывает необходимость авралов.
E>- человеческий фактор (разные уровни подготовки программистов, разные уровни производительности одного и того же программиста в зависимости от ряда факторов (семейные проблемы, увлеченность задачей, взаимоотношения в коллективе, приближение/отдаление очередного отпуска,...), отпуска, больничные, увольнения, ...);
Никоим образом не доказывает необходимость авралов.
E>- постоянный прогресс в инструментах (языки программирования, технологии, библиотеки и фреймворки);
Никоим образом не доказывает необходимость авралов.
AVK>>Т.е, когда заключали договор с заказчиком, тебя даже не спросили, готов ли ты работать в выходные?
E>У меня спросили, смогу ли я сделать эту программу вовремя и я прекрасно понимал, что придется работать в выходные.
Ну тогда при чем тут специфика профессии? Ты сам, своими руками, создал себе авралы. Это специфика не профессии, а тебя лично.
E>>> Может тебе везло?
AVK>>Все время везти не может.
E>Если речь идет о последних пяти годах -- так это даже и не срок.
Про 5 лет я просто доподлинно помню. Массовых авралов у меня не было после того, как я сдал сессию на 3 курсе института, т.е. 12 лет назад.
AVK>>А ты работаешь в стартапе?
E>Ну еще пару лет назад мы были типичным стартапом.
Здравствуйте, AndrewVK, Вы писали:
AVK>Про 5 лет я просто доподлинно помню. Массовых авралов у меня не было после того, как я сдал сессию на 3 курсе института, т.е. 12 лет назад.
А можно личный вопрос? Что такого страшного было на 3-м курсе?
Здравствуйте, AndrewVK, Вы писали:
E>> Но и ты не можешь ее опровергнуть без объективных доказательств.
AVK>А я и не должен ее опровергать. Впрочем, аргументы твоего уровня у меня тоже есть — последние 5 лет у меня не было ни одного аврала. Причем, суть твоей гипотезы такова, что сколь угодно большое количество положительных примеров, если это количество существенно меньше общего их числа, твою гипотезу не доказывают, зато единственный отрицательный пример спогсобен ее опровергнуть.
Если мне здесь 100 человек скажут, что у них за последние 5 лет не было авралов и только 99 скажут, что авралы были, я признаю ошибочность своих предположений.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
AVK>А с чего ты взял, что авралы это часть профессиональной специфики программирования?
Уважаемые читатели форума. На этом месте у нас с AndrewVK возник спор, который завершился моим обещанием, что я признаю свою неправоту, если большинство читателей укажут, что за последние 5 лет у них не было авралов на работе.
Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Прошу просто подтверждать факт было/не было. Понятно, что аврал -- это не хорошо, поэтому не нужно своими оценками высказывать свое отрицательное/положительное отношение к этому явлению.
И еще одна штука -- у меня появилась мысль собрать и опубликовать коллекцию различных ситуаций, приведших к авралам/переработкам и пр. Если у кого-то есть желание поделиться своими воспоминаниями -- прошу присылать их мне на мыло: eao197 на yahoo com
Спасибо!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Хочу заметить, что авралы не столько "следствие специфики программирования", сколько следствие комбинации человеческих слабостей и "специфики программирования" (точнее ситуации, когда можно некий период времени заниматься "черной магией" с обещанием результата "потом" и неумением "работодателя" проконтроллировать промежуточные результаты). В качестве иллюстрации: из друзей у меня программистов с гулькин нос, а авралы у них (не программистов) таки бывают.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, eao197, Вы писали:
ANS>Хочу заметить, что авралы не столько "следствие специфики программирования", сколько следствие комбинации человеческих слабостей и "специфики программирования" (точнее ситуации, когда можно некий период времени заниматься "черной магией" с обещанием результата "потом" и неумением "работодателя" проконтроллировать промежуточные результаты). В качестве иллюстрации: из друзей у меня программистов с гулькин нос, а авралы у них (не программистов) таки бывают.
Я вовсе не хотел сказать, что программисты единственные, кто сталкивался с авралами. Более того, за прошедшее с моего высказывания время я прочел автобиографию Ричарда Брэнсона и пришел к выводу, что наши программиские авралы -- это так, еще цветочки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Я вовсе не хотел сказать, что программисты единственные, кто сталкивался с авралами. Более того, за прошедшее с моего высказывания время я прочел автобиографию Ричарда Брэнсона
Здравствуйте, eao197, Вы писали:
E>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Ставлю минус. Во-первых, за постановку вопроса. Правильный вопрос, должен был прозвучать от тебя следующим образом: были ли у вас на работе за последние 5 лет периодические авралы, случающиеся постоянно. Во-вторых, у меня за последние 5 лет периодических авралов, случающихся постоянно не было.
Если нам не помогут, то мы тоже никого не пощадим.
E>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
А с чего ты взял, что авралы это часть профессиональной специфики программирования?
Похоже, что я пропустил одно ключевое слово: "эпизодически". Я подразумевал "эпизодическое вкалывание до усеру".
Так что прошу привести мне цитату, где бы я говорил, что у любого программиста будут постоянные периодические авралы. Как метко заметил IT, это я про себя сказал
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, eao197, Вы писали:
E>>Я вовсе не хотел сказать, что программисты единственные, кто сталкивался с авралами. Более того, за прошедшее с моего высказывания время я прочел автобиографию Ричарда Брэнсона
BZ>за 17 минут?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Deff, Вы писали:
S>>>Да ну, правда што ли? И какая же часть модели Изи и Оси описывает, к примеру, использование протоколом нижнего уровня протокола верхнего уровня? См. ICMP vs IP. D>>Не могу прокомментировать, т.к. ваша мысль мне непонятна. S>Поясняю мысль: TCP/IP не вырос из модели ISO/OSI. Он ей противоречит.
Признаю ошибку, TCP/IP не вырос из модели OSI.
формально она возникла между где-то между первой и четвертой версией стека TCP/IP,
меня видимо сбили с толку сходства в использовании вертикального
и горизонтального обмена данными в обоих.
D>>Концептуальность модели OSI просто не позволяет искать в ней описания тех или иных D>>аспектов реализации каких-либо стеков (т.к. последнее просто набор частностей). S>Вполне себе позволяет.
возможно, вы правы. видимо стоит лучше ознакомиться с наследием умершей ISO/OSI.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, shrecher, Вы писали:
S>>К счастью или к сожелению, весь процесс реализации распадаются на под задачи, каждая из которых, требует небольшого, но архитектурного решения, где требуется незаурядный мозг. Изначально идея проекта может быть очень классная, но чтобы ее осущетсвить нужны таланты. GZ>По опыту скажу так. Не столь важно что программа глючная, тормозная и т.д. Важна сама идея, и умение ее продать. И если ты не крутой монополист, то максимум чего произойдет — то что конкуренты напишут то же самое и пользователи постепенно уйдут к ним. Все продукты отличаются своими недостатками. Выигрывают те продукты, которые лучше умеют продавать.
вы ошибаетесь. Реализация идей важна неменьше (если не больше), чем сама концепция.
Пример gmail.com и yahoo!mail. Идея одна и таже, возможности продаж практически одинаковые. Но насколько gmail лучше yahoo! Удобнее, просто качественее, поэтому люди к и идут в gmail.
Сейчас, для каждой "крутой" идеи есть конкурент. Успех продукта определяется качеством его реализации.
Здравствуйте, eao197, Вы писали:
E>В ней говорилось, что один из типов безнадежных проектов -- это проекты, где сроки сдачи проектов на 50% меньше, чем это необходимо. Реализация такого проекта -- это сам по себе один сплошной аврал.
А еще говорилось, что для проектов длиной больше ~1 месяца сверхурочная работа не сокращает сроки, а увеличивает их. Потому что усталость накапливаются, люди делают больше ошибок и дольше их исправляют. Если работать в аврале достаточно долго, то эффективность становится отрицательной — то есть на исправление ошибок потом уйдет больше времени, чем на разработку той же функциональности с нуля в нормальном режиме работы.
Сократить сроки можно только за счет (а) урезания фич или (б) урезания этапа отладки и багфиксинга (который в нормальном проекте составляет около 2/3 общего срока). Нормальные менеджеры идут по пути (а), все остальные — по пути (б) и в результате получают очередное непригодное к нормальному употреблению угребище, но зато формально сделали всё что должны были и в срок.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>В ней говорилось, что один из типов безнадежных проектов -- это проекты, где сроки сдачи проектов на 50% меньше, чем это необходимо. Реализация такого проекта -- это сам по себе один сплошной аврал.
AF>А еще говорилось, что для проектов длиной больше ~1 месяца сверхурочная работа не сокращает сроки, а увеличивает их. Потому что усталость накапливаются, люди делают больше ошибок и дольше их исправляют. Если работать в аврале достаточно долго, то эффективность становится отрицательной — то есть на исправление ошибок потом уйдет больше времени, чем на разработку той же функциональности с нуля в нормальном режиме работы. AF>Сократить сроки можно только за счет (а) урезания фич или (б) урезания этапа отладки и багфиксинга (который в нормальном проекте составляет около 2/3 общего срока). Нормальные менеджеры идут по пути (а), все остальные — по пути (б) и в результате получают очередное непригодное к нормальному употреблению угребище, но зато формально сделали всё что должны были и в срок.
Хороше описание очередной крайности. Для достоверности, однако, нужно подтвердить тезис об "очередном уробище". Или это из вашего личного опыта?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Хороше описание очередной крайности. Для достоверности, однако, нужно подтвердить тезис об "очередном уробище". Или это из вашего личного опыта?
Это не крайность, это суровая правда жизни. Менеджер либо понимает, что дерево нельзя заставить расти быстрее, вытягивая его за верхушку, либо не понимает. Других вариантов нет.
И что тут подтверждать? Многие люди принципиально не ставят новые версии программ именно из этих соображений. "Вот выйдет первый сервиспак, тогда и поставлю". В опенсорсе всё вообще в открытую, нечетные билды — "нестабильные"
Здравствуйте, shrecher, Вы писали:
GZ>>Выигрывают те продукты, которые лучше умеют продавать.
S>вы ошибаетесь. Реализация идей важна неменьше (если не больше), чем сама концепция. S>Пример gmail.com и yahoo!mail. Идея одна и таже, возможности продаж практически одинаковые. Но насколько gmail лучше yahoo! Удобнее, просто качественее, поэтому люди к и идут в gmail.
Эээ — нет. Тут сыграла идея + сетевой маркетинг. Идея — 2 гигабайта для каждого + Ajax. 2 гига никто не предлагал. В основном у конкурентов было по 10-20 мегабайт. И об этом трубилось на каждом втором сайте связанных с интернетом. В том числе и на google.com. Ну а во вторых, сетевой маркетинг. В gmail можно было попасть только по приглашению. А запретный плод сладок. Скорость распространения такого маркетинга — экспоцентиальный. Были организованы сайты по раздаче запретного плода(не удивлюсь при помощи gmail, по крайней мере они не мешали). Вот и получилось что gmail захватил огромнейший сегмент рынка у огромного количества конкурентов(не только yahoo).
Что касается удобности, то тот же outlook на порядок удобнее. Структурировать письма неудобно. Мастера outlook на порядок удобнее. Я подписан на rsdn — мне пришлось спускать все rsdn-письма в корзину. Иначе я не разберусь с основной информацией. Через тегирование работать неудобно по сравнению с папками. Несколько ящиков можно настроить только через пересылку. Если ходить с медленной сети, то войти на него очень проблематично. Вобщем, много отстойного.
S>Сейчас, для каждой "крутой" идеи есть конкурент. Успех продукта определяется качеством его реализации.
Ты привел как раз пример гениальной идеи.
Специфика,
спецификум (отпозднелатинского specificus — особый, особенный), особенности, присущие только данному предмету, явлению или роду, классу предметов, явлении; существенные признаки, отличающие данный объект от всех других, например С. профессии летчика, С. искусства, С. издания.
БСЭ
Специфика,
AVK>спецификум (отпозднелатинского specificus — особый, особенный), особенности, присущие только данному предмету, явлению или роду, классу предметов, явлении; существенные признаки, отличающие данный объект от всех других, например С. профессии летчика, С. искусства, С. издания.
AVK>БСЭ
И?
Где я утвержал, что "специфика программирования" == авралы? Если я правильно понимаю наш спор, ты мы выясняем, являются ли авралы частью специфики программированием (на ряду с другими явлениями) или не являются.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, minorlogic, Вы писали:
M>>Не подтосовывай факты , речь шла о ПОСТОЯННЫХ , ПЕРИОДИЧЕСКИХ авралах , а раз в 5 лет бывает аврал и у дворника
E>Где она шла об этом? E>Спор начался отсюда: http://www.rsdn.ru/forum/message/2733239.1.aspx
E>[q] E>>Программисты здесь конечно не что-то уникальное. Наверняка есть еще масса профессий, в которых неожиданные авралы являются частью профессиональной специфики.
Тогда поясни, что такое "профессиональная специфика" ? то что бывает на работе раз в 5 лет ? у меня за 5 лет даже не раз понос был (извините за подробность), это "профессиональная специфика" ?
'When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean--neither more nor less.'
Здравствуйте, minorlogic, Вы писали:
M>Тогда поясни, что такое "профессиональная специфика" ? то что бывает на работе раз в 5 лет ? у меня за 5 лет даже не раз понос был (извините за подробность), это "профессиональная специфика" ?
А причин, по которым работать приходится гораздо больше и/или напряженнее в программировании достаточно:
— сложность выуживания из заказчика конкретных пожеланий и спецификаций;
— излишний оптимизм менеджеров, проектировщиков, разработчиков;
— сложность перевода ментальных моделей, существующих в головах проектировщиков/разработчиков, в программный код;
— баги, допущенные как из-за недопонимания предметной области, так и из-за элементарных опечаток;
— человеческий фактор (разные уровни подготовки программистов, разные уровни производительности одного и того же программиста в зависимости от ряда факторов (семейные проблемы, увлеченность задачей, взаимоотношения в коллективе, приближение/отдаление очередного отпуска,...), отпуска, больничные, увольнения, ...);
— постоянный прогресс в инструментах (языки программирования, технологии, библиотеки и фреймворки);
— и, наверняка, что-то еще
Я согласен с AndrewVK, что ни один из этих пунктов не может гарантированно привести к авралу. Я даже готов поверить, что есть люди, которые делают минимум ошибок при постановке задачи, проектировании и кодировании. Что благодоря своим способностям и опыту они сводят риски к минимуму и избегают авралов.
Тем не менее, вероятность того, что на каждом уровне будет допущена серьезная ошибка, слишком велика, чтобы ей пренебрегать. А в совокупности все это образует очень "тонкий лед", любой неверный шаг по которому способен привести к увеличению трудозатрат и переработкам. И поводов к ошибкам на любом уровне может быть слишком много.
Мне трудно судить об управлении программными проектами, об архитектуре и проектировании крупных систем, но вот что я считаю очень характерной для программирования вещью, так это преобразование тех идей, которые находятся в голове программиста (постановщика задачи, проектировщика), в программный код.
Например, программист может прочитать в ТЗ, что нормальным условием для парового котла будет температура, не превышающая 100 градусов. И совершенно спокойно записать:
if( t < 100 )
normal_mode();
else
alarm_mode();
И только впоследствии кто-то обнаружит, что 100 градусов -- это допустимая температура. Но поздно, ошибка допущена (просто потому, что для кого-то "не превышает" эквивалентно "строго меньше") и хорошо, если она будет обнаружена быстро.
Еще хуже, что во время проектирования мы находимся на "своей волне", у нас есть ряд "умолчаний", которые мы неявно воспринимаем и не отдаем себе отчета о том, что их нужно декларировать явно в программе или технических документах. Например, мне как-то от смежников пришел документ, описывающий структуру необходимой им информации (они делали расчеты, а мы обеспечивали связь между компонентами и занимались передачей данных). Так вот в документе описывалась структура пакета вида:
и пояснение, что элементами векторов X являются комплексные числа. Соответственно, все так и было сделано. Когда же мы привезли свою часть на интеграцию оказалось, что вектор X -- это не вектор комплексных чисел, это вектор, каждый элемент которого состоял из матрицы Y и векторов X1 и X2 (!!!). Просто автор документа не задумался о том, насколько точно написанное им отражает его собственные представления. А ошибка оказалась офигенная -- объем одного пакета увеличивался сразу в 4-5 раз. Соответственно и объем расчетов на каждом из узлов увеличился соответственно, поэтому даже расчет перестал помечаться в отведенный по ТЗ интервал времени. Уж хрен знает, о чем они думали, но в результате пришлось по ходу править ТЗ и изменять заявленные в нем параметры.
Это все к тому, что программирование -- это та область, где ошибки поджидают на каждом шагу и проявляются в самое неподходящее время. Сюда же нужно добавить и внешние факторы. Менеджеры часто настаивают на сжатых сроках из-за конкуренции, программисты берут на себя повышенные обязательства из-за излишней самоуверенности, желания карьерного роста, прибавки к зарплате, неопытности и еще хрен знает чего.
Так что ошибаются все -- менеджеры, проектировщики, программисты, тестировщики, документаторы. Кто-то меньше, кто-то больше. Но все равно, рано или поздно ошибки случаются. В чем точно можно быть уверенным в программировании -- так это в том, что в вашей программе всегда есть ошибка.
А авралы и переработки -- это попытки исправления допущенных ранее ошибок. Причем чем на более ранней стадии и на более высоком уровне была допущена ошибка, тем больше усилий приходится прилагать. Ну или отказываться от чего-то (функциональности или качества, как сказал AndreiF).
Так что одним из главных факторов, обуславливающих возникновение авралов у программистов я считаю ошибки и просчеты (в широком смысле этого слова). Но это, к сожалению, не единственные факторы...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei F., Вы писали:
AF>И что тут подтверждать? Многие люди принципиально не ставят новые версии программ именно из этих соображений. "Вот выйдет первый сервиспак, тогда и поставлю". В опенсорсе всё вообще в открытую, нечетные билды — "нестабильные"
Я не знаю особенностей разработки коробочного ПО, но с заказным ПО ситуация не такая однозначная. Заказчики платят за реализацию нужной им функциональности. И зачастую не откладывают переход на новые версии (более того, иногда даже не имеют возможности отложить этот переход), поскольку они не могут обходится без того, что заказали (могли бы -- не заказывали ).
А со свободным ПО ситуация вообще особенная, там жесткие сроки релизов -- это редкость, имхо. Да и отделов контроля качества нет -- пользователи как раз таким отделом и являются
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Плюс поставил, потому что авралы были. К самому спору: специфическими для нашей профессии их не считаю.
Если бы ты сказал что нибудь вроде "У программистов бывают авралы", то вряд ли кто нибудь с тобой бы спорил
Насколько я понял, именно об этом говорит твой опыт. А вот то, что "авралы это часть профессиональной специфики программирования" — это уже вывод, который ты сделал из этого опыта. Может просто вывод неверен? Приведи цепочку рассуждений
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, eao197, Вы писали:
E>>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
L>Плюс поставил, потому что авралы были.
Спасибо, это именно то, что и требовалось.
L>К самому спору: специфическими для нашей профессии их не считаю. L>Если бы ты сказал что нибудь вроде "У программистов бывают авралы", то вряд ли кто нибудь с тобой бы спорил L>Насколько я понял, именно об этом говорит твой опыт. А вот то, что "авралы это часть профессиональной специфики программирования" — это уже вывод, который ты сделал из этого опыта. Может просто вывод неверен? Приведи цепочку рассуждений
Здравствуйте, minorlogic, Вы писали:
M>при чем тут эти рассуждения ? я просто указывал что предложенное тобой голосование неадекватно, а ты рассуждаешь про что то другое.
Здравствуйте, eao197, Вы писали:
E>Я не знаю особенностей разработки коробочного ПО, но с заказным ПО ситуация не такая однозначная. Заказчики платят за реализацию нужной им функциональности. И зачастую не откладывают переход на новые версии (более того, иногда даже не имеют возможности отложить этот переход), поскольку они не могут обходится без того, что заказали (могли бы -- не заказывали ).
С заказным ПО все еще проще — можно точно узнать у заказчика, что ему нужно сделать немедленно, а какие рюшечки можно отложить на потом. И нет никакой необходимости работать больше нормы.
Здравствуйте, eao197, Вы писали:
E>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
Ты до хрипоты спорил о переодических авралах, а в доказательство этому спрашиваешь бил ли у людей хотя бы один аврал за последние 5 лет (ведь утверждению "если у вас за последние 5 лет были авралы" удовлетворяет наличие даже одного аврала). Или ты так понимашь термин "переодические"? Мне почему-то кажется, что переодичискими авралами нельзя назвать авралы происходящие раз в несколько лет.
ЗЫ
А теперь открою срашный сикрет. Это импровизированное голосование показывает не то насколько овралы специфичны для некой области, а уровень проффевсионализма. Очевидно, что если люди не могут без оралов сдавать свою работу, то их уровень не высок.
Аврал ни что иное как попытка сделать работу которую надо было делать несколько месяцев (а то и лет) за короткий промежуток времени (неделю, а то и ночь).
Если уж случилось, так, что вы не верно оценили свои силы или открылись новые, неведомые обстоятельства приведщие к срыву сроков, то лучше отказаться от части фунциональности или увеличить срок. Работа сделанная в полусне на коефе/чае/кофение/экстази заведомо некачественна.
Так что всем кто поставил тут плюсик очень советую задуматься над тем, что не так в их жизни.
Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду. "Постоянные переодические овралы" (тм) были частью моей жизни где-то до 2000-го года. И только сейчас я понял, что это были проявления нашей безолаберности и неоптытности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
eao197 категоричен и потому не прав. Так же дело обстоит и с тобой, с чего ты взял, что если "авралы происходят раз в несколько лет", то отсюда очевидно, что "люди не могут без оралов сдавать свою работу"?
Здравствуйте, VladD2, Вы писали:
E>>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
VD>Ты до хрипоты спорил о переодических авралах, а в доказательство этому спрашиваешь бил ли у людей хотя бы один аврал за последние 5 лет (ведь утверждению "если у вас за последние 5 лет были авралы" удовлетворяет наличие даже одного аврала). Или ты так понимашь термин "переодические"? Мне почему-то кажется, что переодичискими авралами нельзя назвать авралы происходящие раз в несколько лет.
По поводу неумения понять простую просьбу и досмысливание чего-то еще см.здесь
VD>А теперь открою срашный сикрет. Это импровизированное голосование показывает не то насколько овралы специфичны для некой области, а уровень проффевсионализма. Очевидно, что если люди не могут без оралов сдавать свою работу, то их уровень не высок.
VD>Аврал ни что иное как попытка сделать работу которую надо было делать несколько месяцев (а то и лет) за короткий промежуток времени (неделю, а то и ночь).
VD>Если уж случилось, так, что вы не верно оценили свои силы или открылись новые, неведомые обстоятельства приведщие к срыву сроков, то лучше отказаться от части фунциональности или увеличить срок. Работа сделанная в полусне на коефе/чае/кофение/экстази заведомо некачественна.
VD>Так что всем кто поставил тут плюсик очень советую задуматься над тем, что не так в их жизни.
...The Standish Group research shows a staggering 31.1% of projects will be cancelled before
they ever get completed. Further results indicate 52.7% of projects will cost 189% of their
original estimates...
...On the success side, the average is only 16.2% for software projects that are completed ontime
and on-budget. In the larger companies, the news is even worse: only 9% of their projects
come in on-time and on-budget. And, even when these projects are completed, many are no
more than a mere shadow of their original specification requirements. Projects completed by the
largest American companies have only approximately 42% of the originally-proposed features
and functions. Smaller companies do much better. A total of 78.4% of their software projects will
get deployed with at least 74.2% of their original features and functions...
“On average, companies start 38 projects annually, less than half of which (42 per cent) are completed on time and on budget, while six per cent are cancelled altogether,” says Carter. “At an average cost of $199,033 per week, projects not completed within the set timeframes are causing companies major budget blowouts.”
Меньше половины проектов заканчиваются вовремя и укладываются в бюджеты. И даже те, что укладываются, содержат далеко не все фичи, которые в них закладывали изначально.
Имхо, эти данные свидетельствует либо о тотальном непрофессионализме занятых в разработке ПО (за редким исключением в виде тех, кто на мою просьбу ответил минусом, естественно), либо о том, что в самом процессе разработки ПО есть что-то особенное. О чем я и пытаюсь сказать.
VD>Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду. "Постоянные переодические овралы" (тм) были частью моей жизни где-то до 2000-го года. И только сейчас я понял, что это были проявления нашей безолаберности и неоптытности.
Не подставляйся, а то у меня есть большое желание "ударить лежачего".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, lomeo, Вы писали:
L>Так же дело обстоит и с тобой, с чего ты взял, что если "авралы происходят раз в несколько лет", то отсюда очевидно, что "люди не могут без оралов сдавать свою работу"?
А я этого не утверждал. Так что и обсуждать не чего. Понятно, что форсмажор или нужда может случаться раз в 5-10 лет. Но если это начинает случаться постоянно, то проблемы надо искать в себе и своих подходах. А те кто считает, что это в норме вещей, скажем так, не совсем правы.
L>Кстати, интересная опечатка (выделено)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Меньше половины проектов заканчиваются вовремя и укладываются в бюджеты. И даже те, что укладываются, содержат далеко не все фичи, которые в них закладывали изначально.
E>Имхо, эти данные свидетельствует либо о тотальном непрофессионализме занятых в разработке ПО (за редким исключением в виде тех, кто на мою просьбу ответил минусом, естественно), либо о том, что в самом процессе разработки ПО есть что-то особенное. О чем я и пытаюсь сказать.
О первом оно свидетельствует. Вообще высококлассных спецов очень мало.
В прочем, разработка ПО тем и отличается, что дисциплина эта творческая, а значит сильно зависящая от человеческого фактора.
Но опять же, ты сам сказал, что "половины проектов заканчиваются вовремя и укладываются в бюджеты" и "содержат далеко не все фичи" — это и есть разумные выходы из ситуации. Не уложились? Значит применяем более быстрые решения и уменьшам объем фич. А штурмовщина — это плохой выход из положения.
В режиме шутрма можно работать день-два. Проекты ведутся обычно годами. Я не вижу смысла в экономии пары дней. А штурм длинной в неделю — это отличный способ добиться переутомления, что приведет к обратному эффекту.
E>Не подставляйся, а то у меня есть большое желание "ударить лежачего".
- Фиона!
— Я Шрэк!
— А мне по фигу...
(с) цирюльник из Шрэк 3.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты до хрипоты спорил о переодических авралах, а в доказательство этому спрашиваешь бил ли у людей хотя бы один аврал за последние 5 лет (ведь утверждению "если у вас за последние 5 лет были авралы" удовлетворяет наличие даже одного аврала). Или ты так понимашь термин "переодические"? Мне почему-то кажется, что переодичискими авралами нельзя назвать авралы происходящие раз в несколько лет.
VD>А теперь открою срашный сикрет. Это импровизированное голосование показывает не то насколько овралы специфичны для некой области, а уровень проффевсионализма. Очевидно, что если люди не могут без оралов сдавать свою работу, то их уровень не высок.
VD>Так что всем кто поставил тут плюсик очень советую задуматься над тем, что не так в их жизни.
Даже тем, у кого как ты верно подметил мог быть всего один аврал?
Не приходила в голову такая мысль, что аврал мог быть вызван причинами, не зависящими от человека?
VD>Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду.
Ещё бы, искажаешь исходные факты — о чём тут спорить.
now playing: Alexi Delano & Xpansul — Pares Y Juego
Здравствуйте, AndrewVK, Вы писали:
AVK>Поздравляю. Однако почему тогда на всех местах, где я работал, я обходился без авралов? Ошибки у меня не той системы?
Скорее — заказчики не той системы. Тепличный вариант, который возможен при наличии очереди заказчиков. Вот мы сейчас делаем проект, на который явно отведено меньше, чем положено, а иначе бы не было проекта, заказчик бы отказался от самой задумки и вложился бы в другое... В то же самое время проект технически невероятно интересен (нам) и область настолько же невероятно актуальна, востребована и денежна настолько, что заказчику дешевле финансировать разработку своей системы в течении года, для "унутреннего применения" чем покупать готовые... да и нам хоть какая-то отдушина после этих идиотских "решений для бизнеса".
Здравствуйте, vdimas, Вы писали:
V>Вот мы сейчас делаем проект, на который явно отведено меньше, чем положено
Кто отвел времени меньше чем положено? Твоим мнением при этом интересовались? Как оплачивается переработка?
V>область настолько же невероятно актуальна, востребована и денежна
Здравствуйте, EvilChild, Вы писали:
EC>Даже тем, у кого как ты верно подметил мог быть всего один аврал?
Если был всего один, то эти люди с огромной вероятностью уже задумались и сделали правильные выводы. Иначе авралы повторялись бы.
EC>Не приходила в голову такая мысль, что аврал мог быть вызван причинами, не зависящими от человека?
Так не бывает. Любой подвиг является результатом чьего-то раздолбайства или глупости.
VD>>Понимаю, что сейчас появится толпа несогласных, но спорить я с ней не буду. EC>Ещё бы, искажаешь исходные факты — о чём тут спорить.
Я искажаю? Ну, ты фантазер.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
V>>Вот мы сейчас делаем проект, на который явно отведено меньше, чем положено
AVK>Кто отвел времени меньше чем положено? Твоим мнением при этом интересовались?
Вопрос стоял так: "можно ли сделать то-то и то-то с выходом на рынок за столько-то недель?". Ответ был — если поднапрячься, то можно.
AVK>Как оплачивается переработка?
Несколько повысилась ЗП у работников всвязи с началом этого проекта.
V>>область настолько же невероятно актуальна, востребована и денежна
AVK>Каким процентом акций предприятия ты владеешь?
Здравствуйте, vdimas, Вы писали:
V>Вопрос стоял так: "можно ли сделать то-то и то-то с выходом на рынок за столько-то недель?". Ответ был — если поднапрячься, то можно.
Ну вот и настоящая причина. А отнюдь не "специфика программирования".
AVK>>Как оплачивается переработка?
V>Несколько повысилась ЗП у работников всвязи с началом этого проекта.
Несколько это сколько? В процентах хотя бы.
AVK>>Каким процентом акций предприятия ты владеешь?
V>Акций пока не выпускал, обхожусь без них.
Ну если это твое личное предприятие, то и говорить не о чем.
V>>Вопрос стоял так: "можно ли сделать то-то и то-то с выходом на рынок за столько-то недель?". Ответ был — если поднапрячься, то можно.
AVK>Ну вот и настоящая причина. А отнюдь не "специфика программирования".
Да просто каждый второй проект примерно такой, в плане сроков. На моей памяти был лишь один проект, который изначально не был лимитирован во времени, и заказчик принял те сроки, которые мы ему сказали (Philips). В остальных случаях шла долгая борьба за то, что включается в первую версию, что во вторую и т.д. И такая борьба всегда на грани фола, т.к. хорошие заказчики и интересные проекты на дороге не валяются. А от автоматизации предприятий (на которые всегда есть спрос в плане разработки) я последние несколько лет стараюсь уходить, ибо наелся лет за 7 до этого. Исключение составили для фирмы "Pioneer", ну только ради громкого имени в портфеле и ограниченных чётких требований к небольшой подсистеме. Просто я как бы знаю (или думаю, что знаю), как правильно писать системы автоматизации предприятий, и потому стараюсь этим не заниматься, дабы не впаривать лажу. По хорошему, начинать надо с собственного языка для модулей имплементации бизнес-рулс, т.к. ни C#, ни VB.Net ни многие другие оформившимся за годы требованиям не удовлетворяют и близко. В итоге это выльется в YA-Axapta или нечто вроде того...
AVK>>>Как оплачивается переработка?
V>>Несколько повысилась ЗП у работников всвязи с началом этого проекта.
AVK>Несколько это сколько? В процентах хотя бы.
Здравствуйте, vdimas, Вы писали:
AVK>>Ну вот и настоящая причина. А отнюдь не "специфика программирования".
V>Да просто каждый второй проект примерно такой, в плане сроков.
Да хоть каждый первый.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
eao197,
AVK>>А я и не должен ее опровергать. Впрочем, аргументы твоего уровня у меня тоже есть — последние 5 лет у меня не было ни одного аврала. Причем, суть твоей гипотезы такова, что сколь угодно большое количество положительных примеров, если это количество существенно меньше общего их числа, твою гипотезу не доказывают, зато единственный отрицательный пример спогсобен ее опровергнуть.
E>Если мне здесь 100 человек скажут, что у них за последние 5 лет не было авралов и только 99 скажут, что авралы были, я признаю ошибочность своих предположений.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
>В качестве иллюстрации: из друзей у меня программистов с гулькин нос, а авралы у них (не программистов) таки бывают.
Я таки подозреваю, что они были, когда программистов и компьютеров вовсе на свете не было
Здравствуйте, eao197, Вы писали:
E>Уважаемые читатели форума. На этом месте у нас с AndrewVK возник спор, который завершился моим обещанием, что я признаю свою неправоту, если большинство читателей укажут, что за последние 5 лет у них не было авралов на работе.
Я поставил плюс, но с большим сомнением. Со старым заказчиком — не было ни разу, да и вообще мы никуда не спешили. Но, увы, проект кончился. С новым — было, и не раз, хоть и не явный аврал, но нечто похожее на это. Теперь вернулся к старому заказчику, надеюсь, опять не будет. От организации все зависит, от задачи, от сроков (разумные или не очень) . В общем, не показатель это ИМХО.
Здравствуйте, eao197, Вы писали:
E>Уважаемые читатели форума. На этом месте у нас с AndrewVK возник спор, который завершился моим обещанием, E> что я признаю свою неправоту, если большинство читателей укажут, что за последние 5 лет у них не было авралов на работе.
А в чем смысл твоего обещания?
С тем же успехом можно было обещать признать свою не правоту, если MS начнет вкладывать бабло в Nemerle, например... =) Причина вашего разногласия и твое обещание, никак между собой не связваны..
E>Поэтому прошу принять участие в нашем споре следующим образом: если у вас за последние 5 лет были авралы на работе, то поставьте на это сообщение "плюсик". Если не было -- минус.
По сути спора, AVK прав, а голосование — полная пурга.. )
Здравствуйте, IB, Вы писали:
E>>Уважаемые читатели форума. На этом месте у нас с AndrewVK возник спор, который завершился моим обещанием, E>> что я признаю свою неправоту, если большинство читателей укажут, что за последние 5 лет у них не было авралов на работе. IB>А в чем смысл твоего обещания?
Смысл в том, что я отстаивал свою точку зрения исходя из собственного опыта и опыта моих знакомых. При этом я считал, что этот опыт является достаточным. Если же достаточное количество участников форума подтвердят, что авралов у них не было, значит мой опыт недостаточен для моих утверждений и, как следствие, я строил свои предположения на ошибочных предпосылках.
IB>По сути спора, AVK прав, а голосование — полная пурга.. )
Спасибо за участие в голосовании.
Все остальные домыслы, упоминания любимого командой RSDN языка и утвержение о правоте AVK -- полная пурга
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Смысл в том, что я отстаивал свою точку зрения исходя из собственного опыта и опыта моих знакомых.
Опыта в чем? В авралах? Да, здесь ты похоже краевед..
E> При этом я считал, что этот опыт является достаточным.
Достаточным для чего?
E> Если же достаточное количество участников форума подтвердят, что авралов у них не было, значит мой опыт недостаточен для моих утверждений и, как следствие, я строил свои предположения на ошибочных предпосылках.
Ты строил свои предположения на ошибочных предпосылках вне зависимости от исхода "голосования". Так как "голосование" не имеет никакого отношения к предположениям.
Так что можешь начинать признавать свою неправоту..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, eao197, Вы писали:
E>>Смысл в том, что я отстаивал свою точку зрения исходя из собственного опыта и опыта моих знакомых. IB>Опыта в чем? В авралах? Да, здесь ты похоже краевед..
Да, я такой: успешное выполнение безнадежных проектов, быстро, качественно, очень дорого. Координаты в профайле.
E>> При этом я считал, что этот опыт является достаточным. IB>Достаточным для чего?
Для того, чтобы придти к мнению, что авралы -- это обычное дело в программировании.
E>> Если же достаточное количество участников форума подтвердят, что авралов у них не было, значит мой опыт недостаточен для моих утверждений и, как следствие, я строил свои предположения на ошибочных предпосылках. IB>Ты строил свои предположения на ошибочных предпосылках вне зависимости от исхода "голосования". Так как "голосование" не имеет никакого отношения к предположениям.
Имхо, мне судить об этом.
IB>Так что можешь начинать признавать свою неправоту..
Пока счет +22 -3 (на 2007.11.28 12:21 московского времени), так что оснований для признания неправоты нет. Равно как и каких-либо осмысленных аргументов от моих опонентов.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да, я такой: успешное выполнение безнадежных проектов, быстро, качественно, очень дорого. Координаты в профайле.
Нафиг-нафиг... Мы лучше неторопять спустимся с горы..
E>Для того, чтобы придти к мнению, что авралы -- это обычное дело в программировании.
Для того чтобы прийти к мнению, что авралы обычное дело в твоем программировании. Чувствуешь разницу?
E>Имхо, мне судить об этом.
IMO — не тебе...
E>Пока счет +22 -3 (на 2007.11.28 12:21 московского времени), так что оснований для признания неправоты нет.
Основания хотя бы в том, что этот счет не имеет никакого отношения к делу..
E> Равно как и каких-либо осмысленных аргументов от моих опонентов.
Как можно давать осмысленные аргументы на полную пургу?
Здравствуйте, IB, Вы писали:
E>>Для того, чтобы придти к мнению, что авралы -- это обычное дело в программировании. IB>Для того чтобы прийти к мнению, что авралы обычное дело в твоем программировании. Чувствуешь разницу?
Для того, чтобы почувстовать разницу я и затеял голосование. Пока я вижу, что не только в моем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
V>>Да просто каждый второй проект примерно такой, в плане сроков.
AVK>Да хоть каждый первый.
Ну вот и вернулись к началу. Если речь о каждом первом — то это уже специфика.
Я вполне понимаю позицию eao197, т.к. заказчикам обычно надо уже готовое решение, а его ж еще надо разрабатывать. Поэтому всегда идёт торг баланса сроки-деньги-набор_фич, и для фирм, которые не могут позволить себе перебирать заказчиками (а таких большинство), сроки обычно забиваются без учёта форс-мажоров, а они периодически бывают, к сожалению, что и приводит к авралам. Я под форс-мажором в плане разработки, понимаю не землетрясения и цунами, а некие технические неувязки, которые могут всплыть даже уже на этапе бета-тестирования, и причинами их могут быть глюки третьесторонних компонентов в определённом окружении. Вот из последнего у нас: реализация RTP от openH323 неусточиво работает на WinXp, хотя отлично пашет на серверных ОС, и эта неустойчивость проявляется при весьма специфических условиях. Был аврал по решению проблемы, куда ж без него...
Здравствуйте, eao197, Вы писали:
E>Для того, чтобы почувстовать разницу я и затеял голосование.
То есть разницу между "хоть раз" и "обычное дело" ты тоже не ощущаешь..
Что вообщем-то и требовалось доказать...
E> Пока я вижу, что не только в моем.
Счастливых авралов..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, eao197, Вы писали:
E>>Для того, чтобы почувстовать разницу я и затеял голосование. IB>То есть разницу между "хоть раз" и "обычное дело" ты тоже не ощущаешь.. IB>Что вообщем-то и требовалось доказать...
Интересно, откуда взялось "хоть раз"? В голосовании я спрашивал про "авралы", во множественном числе.
E>> Пока я вижу, что не только в моем. IB>Счастливых авралов..
Спасибо. Как раз сейчас предстоит участвовать в проекте, срок реализации которого был сокращен с 4-х месяцев до 3-х.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Специфика многомерных задач, ИМХО. Не секрет, что строители проси..ают сроки гораздо реже разработчиков ПО. Не думаю, что строители гораздо умнее разработчиков, дело в многомерности задач. Для строителя не природный форс-мажор — это, например, закрылся завод поставщика, а другие производители не смогли вовремя его заменить из-за уже расписанных поставок. Вероятность подобных форс-мажоров крайне низка, в отличие от специфических глюков ПО, с которым должно взаимодействовать твоё разрабатываемое (и с ОС в т.ч.) — к сожалению слишком частый и плохо прогнозируемый форс-мажор. И в большинстве случаев, зараза, не проявляет себя на этапе моделирования и технического эксперимента.
И я не приемлю прозвучавших тут советов, типа: "надо разумно изменить состав реализованных к оговоренному сроку фич", и тем паче как издевательство прозвучавшее добавление, что это "профессинально". В глазах заказчика это архинепрофессионально и мне пока не попадались другие заказчики. Может, у меня заказчики не той системы? (С) здешний.
В принципе, несколько дней (неделю) иногда можно и на кофе посидеть, если потом "на свободу с чистой совестью" и незапятнанной репутацией.
В общем, каждый выбирает как ему внутренне комфортней, мне так.
Здравствуйте, vdimas, Вы писали:
AVK>>Вопрос только в том — специфика чего.
V>Специфика многомерных задач, ИМХО.
Каких каких?
V> Не секрет, что строители проси..ают сроки гораздо реже разработчиков ПО.
Статистику в студию.
V> Не думаю, что строители гораздо умнее разработчиков, дело в многомерности задач.
Нет, дело в том, что заказчик в строительстве обычно несколько лучше разбирается, нежели в программировании. А, значит. ушлым менеджерам легче навешать лапшу на уши.
V>Вероятность подобных форс-мажоров крайне низка
Тем не менее сдача зданий приемке сильно задерживалась и при советской власти, и сейчас. Собственно, ни у кого из моих знакомызх, кто покупал квартиры в недостроенных домах не сдали дом во время.
V>, в отличие от специфических глюков ПО, с которым должно взаимодействовать твоё разрабатываемое (и с ОС в т.ч.) — к сожалению слишком частый и плохо прогнозируемый форс-мажор. И в большинстве случаев, зараза, не проявляет себя на этапе моделирования и технического эксперимента.
Это все понятно. Но при чем тут авралы? Это вполне нормальные риски, которые просто надо учитывать. А строить прогнозы по абсолютно оптимистичным оценкам, да потом еще отщипывать от этого прогноза куски, типа срочно надо, так тогда проблемы обеспечены. Только это специфика не программирования.
V>И я не приемлю прозвучавших тут советов, типа: "надо разумно изменить состав реализованных к оговоренному сроку фич", и тем паче как издевательство прозвучавшее добавление, что это "профессинально".
Надо не "разумно и профессионально", надо просто закладываться на риски. Конкретный риск предсказать сложно, но суммарная задержка вполне легко прогнозируется. Надо только про это не забывать.
V>В принципе, несколько дней (неделю) иногда можно и на кофе посидеть, если потом "на свободу с чистой совестью" и незапятнанной репутацией.
Вот ты и демонстрируешь то, что твои авралы это лично твой взгляд на допустимость этих авралов. И eao тоже сам признал, что он сам и назвал заведомо невыполнимый в нормальном режиме срок. Так при чем тут тогда программирование?
V>В общем, каждый выбирает как ему внутренне комфортней, мне так.
Вот именно. И не надо валить на программирование.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
V>>В принципе, несколько дней (неделю) иногда можно и на кофе посидеть, если потом "на свободу с чистой совестью" и незапятнанной репутацией.
AVK>Вот ты и демонстрируешь то, что твои авралы это лично твой взгляд на допустимость этих авралов. И eao тоже сам признал, что он сам и назвал заведомо невыполнимый в нормальном режиме срок. Так при чем тут тогда программирование?
Потому, что тогда бы этот срок назвал бы кто-то из конкурентов и заказ ушел бы к ним.
Ну и кроме того, программирование таки позволяет очень серьезно сжимать сроки, если это нужно.
V>>В общем, каждый выбирает как ему внутренне комфортней, мне так.
AVK>Вот именно. И не надо валить на программирование.
Тогда что в твоем понимании программирование -- только написание и компилирование программ?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Потому, что тогда бы этот срок назвал бы кто-то из конкурентов и заказ ушел бы к ним.
И где здесь специфика программирования?
E>Ну и кроме того, программирование таки позволяет очень серьезно сжимать сроки, если это нужно.
Ты заблуждаешься. Авралить можно точно так же почти в любом виде инженерной деятельности. С точнотакими же последствиями.
AVK>>Вот именно. И не надо валить на программирование.
E>Тогда что в твоем понимании программирование -- только написание и компилирование программ?
В моем понимании программирование это прежде всего техническая дисциплина. И уж понятие о risk management в него точно не входит.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
E>>Ну и кроме того, программирование таки позволяет очень серьезно сжимать сроки, если это нужно.
AVK>Ты заблуждаешься. Авралить можно точно так же почти в любом виде инженерной деятельности. С точнотакими же последствиями.
Программирование -- это не чистая инженерная деятельность, но еще и производство.
Попробуй, например, во время ремонта стяжку на пол положить, и не дать ей просохнуть отведенное время. А в программировании можно прогнать unit-тесты и сразу же программу в боевую эксплуатацию, под реальную нагрузку. А можно и вообще без тестов, есть и такие программисты.
AVK>>>Вот именно. И не надо валить на программирование.
E>>Тогда что в твоем понимании программирование -- только написание и компилирование программ?
AVK>В моем понимании программирование это прежде всего техническая дисциплина. И уж понятие о risk management в него точно не входит.
С этого нужно было начинать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Программирование -- это не чистая инженерная деятельность, но еще и производство.
AVK>Сути дела это не меняет.
Ну ни херасе...
E>>Попробуй, например, во время ремонта стяжку на пол положить, и не дать ей просохнуть отведенное время.
AVK>Ха, такое сплошь и рядом.
И что, потом хороший пол получается?
E>> А в программировании можно прогнать unit-тесты и сразу же программу в боевую эксплуатацию, под реальную нагрузку.
AVK>И что? В программировании можно вообще юнит-тесты не прогонять. При чем тут авралы?
При том, что в программировании не соблюдение технологии и/или нормального расписания работы все равно способно приводить к качественным результатам. Что позволяет выправлять различные огрехи (менеджеров или программистов) или форс-мажоры с помощью сверхурочной работы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>>>Программирование -- это не чистая инженерная деятельность, но еще и производство.
AVK>>Сути дела это не меняет.
E>Ну ни херасе...
Во-первых осторожнее с выражениями, во-вторых на производстве, если это не конывеер, авралы очень даже приключаются.
AVK>>Ха, такое сплошь и рядом.
E>И что, потом хороший пол получается?
Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.
AVK>>И что? В программировании можно вообще юнит-тесты не прогонять. При чем тут авралы?
E>При том, что в программировании не соблюдение технологии и/или нормального расписания работы все равно способно приводить к качественным результатам.
Насчет технологии ну очень вряд ли. Только не надо мне рассказывать, что юнит-тесты это то, что должно присутствовать обязательно.
E> Что позволяет выправлять различные огрехи (менеджеров или программистов) или форс-мажоры с помощью сверхурочной работы.
В более менее долгой перспективе ни к чему это, окромя лишних багов, не приводит. Я ж говорю — авралы это вопрос мироощущения. Если кто то не считает возможным быть более менее предсказуемым по срокам — это его личные проблемы. Не надо только переносить их на свойства мироздания.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
E>>>>Программирование -- это не чистая инженерная деятельность, но еще и производство.
AVK>>>Сути дела это не меняет.
E>>Ну ни херасе...
AVK>Во-первых осторожнее с выражениями, во-вторых на производстве, если это не конывеер, авралы очень даже приключаются.
У бухгалтеров, например, при завершении кварталов и финансового года. То же, кстати, специфика работы
AVK>>>Ха, такое сплошь и рядом.
E>>И что, потом хороший пол получается?
AVK>Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.
А где я говорил, что авралы обязательно длительные?
Про регулярность авралов говорил, помню. А вот про длительность?
AVK>>>И что? В программировании можно вообще юнит-тесты не прогонять. При чем тут авралы?
E>>При том, что в программировании не соблюдение технологии и/или нормального расписания работы все равно способно приводить к качественным результатам.
AVK>Насчет технологии ну очень вряд ли. Только не надо мне рассказывать, что юнит-тесты это то, что должно присутствовать обязательно.
Тем не менее, чем серьезнее ПО, тем более формальный процесс разработки. И запуск ПО в эксплуатацию, вроде бы не должен происходить без участия отдела контроля качества ПО, без синхронизации с отделом документирования и пр.
E>> Что позволяет выправлять различные огрехи (менеджеров или программистов) или форс-мажоры с помощью сверхурочной работы.
AVK>В более менее долгой перспективе ни к чему это, окромя лишних багов, не приводит.
Опять же я не говорил о долгой перспективе.
Хотя я знаю примеры довольно крупных контор, в которых в разрабатываемых годами проектах время от времени устраивают bug hunting day, да еще в выходной. Аврал? Аврал, но он же не длится месяцами время. И мироощущение разработчиков/тестировщиков там никого не интересует -- ты либо работаешь, либо идешь против корпоративных правил.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Интересно, откуда взялось "хоть раз"? В голосовании я спрашивал про "авралы", во множественном числе.
Ты спрашивал про единичные авралы, а не систематические.
E>Как раз сейчас предстоит участвовать в проекте, срок реализации которого был сокращен с 4-х месяцев до 3-х.
Ну и сами себе кузнецы...
Здравствуйте, AndrewVK, Вы писали:
AVK>А что, при программировании ночами и выходными длительное время получается хороший софт.
Ну, по моему ИМХО, авралы принципиально не могут длиться более недели, иначе действительно надо согласовывать новые сроки. Аврал оправдан только тогда, когда в результате укладываемся в какой-нить deadline (плюс/минус пару дней), что есть несомненный плюс. А после аврала запросто можно дать пару лишних выходных.
Здравствуйте, eao197, Вы писали:
E>У бухгалтеров, например, при завершении кварталов и финансового года. То же, кстати, специфика работы
Когда у всех вокруг одна и та же специфика, то это уже не специфика.
AVK>>Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.
E>А где я говорил, что авралы обязательно длительные? E>Про регулярность авралов говорил, помню. А вот про длительность?
А регулярные авралы это и есть длительный период. Понимаешь, я ведь тут никоим образом не утверждаю, что знаю способ со стопроцентной вероятностью предсказать сроки. Ну то есть, при наличии регулярных майлстоунов и жесткого требования укладывать к ним все запланированное, рано или поздно факап приключится. Но вот когда авралы становятся регулярными, это уже говорит о том, что проблема именно спланированием. И вы это оба подтверждаете — вы сознательно идете на авралы.
AVK>>Насчет технологии ну очень вряд ли. Только не надо мне рассказывать, что юнит-тесты это то, что должно присутствовать обязательно.
E>Тем не менее, чем серьезнее ПО, тем более формальный процесс разработки.
Никоим образом (и юнит-тесты, вообще то, перпендикулярны формальности). Формальность процесса разработки зависит не от размера проектов. а от стиля, принятого в команде. Какие то команды работают с большим количеством формализма, какие то с меньшим. И, что характерно, совсем не ясно в итоге, у кого получается лучше. И тот и другой подходы имеют свои достоинства и недостатки.
AVK>>В более менее долгой перспективе ни к чему это, окромя лишних багов, не приводит.
E>Опять же я не говорил о долгой перспективе.
Регулярные авралы это и есть долгая перспектива.
E>Хотя я знаю примеры довольно крупных контор, в которых в разрабатываемых годами проектах время от времени устраивают bug hunting day, да еще в выходной.
Я тоже. И что? Я еще знаю массу контор, которые обходятся без этого. Нет единственно правильного подхода к управлению разработкой, нет даже вух единственно правильных подходов.
E>И мироощущение разработчиков/тестировщиков там никого не интересует -- ты либо работаешь, либо идешь против корпоративных правил.
Ну вот в итоге они и получают вполне конкретный уровень девелопмента.
Вот только ... Открою тебе один секрет. Даже в таких формализованных конторах как правило есть небольшой тим "реаниматоров", который, когда подобные правила ломаются на нестандартных задачах, вытягивают проект из глубокой ямы.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, vdimas, Вы писали:
AVK>>А что, при программировании ночами и выходными длительное время получается хороший софт.
V>Ну, по моему ИМХО, авралы принципиально не могут длиться более недели
Дело не в том, сколько длится конкретный аврал, дело в том насколько аврал является обычным явлением.
V>Аврал оправдан только тогда, когда в результате укладываемся в какой-нить deadline (плюс/минус пару дней), что есть несомненный плюс.
Аврал не оправдан никогда, просто иногда деваться некуда.
V> А после аврала запросто можно дать пару лишних выходных.
Смешно.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, eao197, Вы писали:
E>>Интересно, откуда взялось "хоть раз"? В голосовании я спрашивал про "авралы", во множественном числе. IB>Ты спрашивал про единичные авралы, а не систематические.
Во-первых, где в моем вопросе было упоминание "единичных" или "хотя бы один"?
Во-вторых, если у двадцати человек за последние пять лет в разных проектах было более одного аврала (вспоминаем про множественное число), то это уже система.
Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
E>>У бухгалтеров, например, при завершении кварталов и финансового года. То же, кстати, специфика работы
AVK>Когда у всех вокруг одна и та же специфика, то это уже не специфика.
Еще раз повторюсь, я утверждал, что авралы -- это только часть специфики программирования.
AVK>>>Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.
E>>А где я говорил, что авралы обязательно длительные? E>>Про регулярность авралов говорил, помню. А вот про длительность?
AVK>А регулярные авралы это и есть длительный период.
Ну ничего подобного. За прошедший год я отработал только 7 или 8 выходных и мой рабочий день очень редко превышал 8 часов. Да, отрабатывать в выходные приходилось регулярно, с периодом в 3-4 месяца. Но вот длительности авралов я здесь не вижу в упор.
AVK>>>В более менее долгой перспективе ни к чему это, окромя лишних багов, не приводит.
E>>Опять же я не говорил о долгой перспективе.
AVK>Регулярные авралы это и есть долгая перспектива.
Ага, длиною в жизнь, надо полагать.
AVK>Вот только ... Открою тебе один секрет. Даже в таких формализованных конторах как правило есть небольшой тим "реаниматоров", который, когда подобные правила ломаются на нестандартных задачах, вытягивают проект из глубокой ямы.
Т.е. shit happens. Вопрос только в везении втоптаться или не втоптаться в него. И если кто-то еще не втоптался, то это пока всего лишь вопрос времени.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Во-первых, где в моем вопросе было упоминание "единичных" или "хотя бы один"?
В твоем вопросе не было "систематических" или "регулярных".
E>Во-вторых, если у двадцати человек за последние пять лет в разных проектах было более одного аврала (вспоминаем про множественное число), то это уже система.
Система — это если бы у всех были регулярные авралы.
А так, вы просто рвете на себе рубаху и занимаетесь нездоровым мазохизмом.
E>Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме.
Это не мы в белом, это... Ну ты понял..
Здравствуйте, IB, Вы писали:
E>>Во-вторых, если у двадцати человек за последние пять лет в разных проектах было более одного аврала (вспоминаем про множественное число), то это уже система. IB>Система — это если бы у всех были регулярные авралы.
Это была бы уже другая система, которая показала бы, что дела в разработке ПО вообще швах.
E>>Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме. IB>Это не мы в белом, это... Ну ты понял..
Да, точно как в притче:
Зима, очень холодно. Летит воробей. Летит из последних сил, замерзает. В конце-концов силы его покидают и он падает на землю.
Лежит он на земле, почти уже не дышит. Мимо проходит корова и мимоходом какает на лежащего воробья.
Оказавшись в теплой коровьей лепешке воробей согревается, возвращается к жизни и начинает чирикать.
Чириканье услышала кошка, раскопала воробья, отчистила и съела.
Мораль: не тот враг, кто тебя в дерьмо посадил, и не тот друг, кто тебя из дерьма вытащил, а если тебе тепло и хорошо -- то сиди тихо и не чирикай.
А вот я что-то расчирикался. Того и гляди ща раскопают и сожрут.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Это была бы уже другая система, которая показала бы, что дела в разработке ПО вообще швах.
Нету никакой системы, есть лишь криворукие менеджеры и безответственные или самоотверженные разработчики...
E>Да, точно как в притче:
Угу. Если тебе с авралами тепло и хорошо, то не пеняй на всю разработку..
Здравствуйте, IB, Вы писали:
E>>Это была бы уже другая система, которая показала бы, что дела в разработке ПО вообще швах. IB>Нету никакой системы, есть лишь криворукие менеджеры и безответственные или самоотверженные разработчики...
И этот факт, естественно, никоим боком к специфике программирования не относится.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>И этот факт, естественно, никоим боком к специфике программирования не относится.
Ну вот, ты начинаешь понимать всю глубину своих заблуждений..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, eao197, Вы писали:
E>>И этот факт, естественно, никоим боком к специфике программирования не относится. IB>Ну вот, ты начинаешь понимать всю глубину своих заблуждений..
А! Я понял! Программирование -- это написание кода в редакторе/IDE, компиляция и, может быть, чуть-чуть потестировать-поотлаживать!
Я-то думал, что это значит взять задачу, решить и сдать заказчику. Со всеми заморочками.
Каюсь, не знал! Так бы помер и не узнал бы
Всем спасибо за науку
Тему можно закрывать и сносить в "Мусор".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Когда у всех вокруг одна и та же специфика, то это уже не специфика.
E>Еще раз повторюсь, я утверждал, что авралы -- это только часть специфики программирования.
Это что то меняет?
AVK>>А регулярные авралы это и есть длительный период.
E>Ну ничего подобного. За прошедший год я отработал только 7 или 8 выходных
Это много, это порядка 9% от оставшихся выходных. Впрочем, что то я тебя не пойму. Ты же сам утверждал что авралы у тебя регулярные.
E> и мой рабочий день очень редко превышал 8 часов. Да, отрабатывать в выходные приходилось регулярно, с периодом в 3-4 месяца. Но вот длительности авралов я здесь не вижу в упор.
Ты уж определись — либо авралы у тебя случаются регулярно, либо это исключительная ситуация.
E>Т.е. shit happens. Вопрос только в везении втоптаться или не втоптаться в него.
Нет, везение тут не при чем.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>Когда у всех вокруг одна и та же специфика, то это уже не специфика.
E>>Еще раз повторюсь, я утверждал, что авралы -- это только часть специфики программирования.
AVK>Это что то меняет?
Только то, что авралы могут быть и частью специфики в других профессиях. Более того, человеческий фактор, наверное, везде одна из самых главных причин авралов. Но в программировании она, к сожалению, не единственная.
AVK>>>А регулярные авралы это и есть длительный период.
E>>Ну ничего подобного. За прошедший год я отработал только 7 или 8 выходных
AVK>Это много, это порядка 9% от оставшихся выходных. Впрочем, что то я тебя не пойму. Ты же сам утверждал что авралы у тебя регулярные.
E>> и мой рабочий день очень редко превышал 8 часов. Да, отрабатывать в выходные приходилось регулярно, с периодом в 3-4 месяца. Но вот длительности авралов я здесь не вижу в упор.
AVK>Ты уж определись — либо авралы у тебя случаются регулярно, либо это исключительная ситуация.
Регулярность и длительность -- это разные вещи. Да, переработки в виде одного-двух выходных на работе встречаются регулярно, где-то раз в три-четыре месяца. Поэтому для меня аврал -- это не исключительная ситуация. Причины самые разные -- собственные просчеты, неожиданно проявившиеся ошибки, внезапные вбрасывания от заказчиков, провалы моих подчиненных и пр.
Тем не менее, длительных авралов, когда бы приходилось пахать несколько недель по 12 и более часов в день, без выходных и пр. у меня, к счастью не было уже давно, лет пять, наверное. Последний раз это случилось, когда человек плюнул на работу и уехал в отпуск. Тогда пришлось его часть буквально вытягивать по ночам чтобы вовремя сдать проект.
Да и вообще, таких серьезных напрягов было еще, наверное, один или два за всю карьеру. В основном при сдаче проектов, когда приходилось сидеть в командировках у заказчика и доводить напильником склепанные разными людьми фрагменты, поскольку отступать уже некуда было. А оставшиеся 99% моих авралов -- это несколько выходных в квартал.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Только то, что авралы могут быть и частью специфики в других профессиях. Более того, человеческий фактор, наверное, везде одна из самых главных причин авралов.
Я там определение слова специфика уже приводил.
AVK>>Ты уж определись — либо авралы у тебя случаются регулярно, либо это исключительная ситуация.
E>Регулярность и длительность -- это разные вещи. Да, переработки в виде одного-двух выходных на работе встречаются регулярно
Ну и не о чем тогда говорить.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, eao197, Вы писали:
E>Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме.
При чём тут вообще IT? Я с тобой не согласен, вот и всё. И не телько я. Тебе из этого следовало бы сделать простой вывод, что если с тобой не согласны, то не стоит делать масштабных обобщений.
Вообще, если порассуждать логически, то после того что вы тут понаговорили с vdimas можно прийти к следующему выводу. Как известно заказчики, избытка в которых вы судя по всему не испытываете, всегда выбирают баланс трёх вещей: сроки, деньги, качество. Учитывая, что сроки у вас всегда сжаты и приходится авралить (т.е. заказчик здесь уже сделал своей выбор), то вы либо продаёте свой товар за офигительно дорого, либо делаете полную лажу.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
E>>Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме.
IT>При чём тут вообще IT? Я с тобой не согласен, вот и всё. И не телько я.
Я и перечислил тех, кто не согласен.
IT>Вообще, если порассуждать логически, то после того что вы тут понаговорили с vdimas можно прийти к следующему выводу. Как известно заказчики, избытка в которых вы судя по всему не испытываете, всегда выбирают баланс трёх вещей: сроки, деньги, качество. Учитывая, что сроки у вас всегда сжаты и приходится авралить (т.е. заказчик здесь уже сделал своей выбор), то вы либо продаёте свой товар за офигительно дорого, либо делаете полную лажу.
Не буду говорить за vdimas, а у нас ситуация такая, что заказчиков слишком много, так как предлагаемые нами продукты и сервисы сейчас очень востребованны. Чем больше сможем удовлетворить сейчас, тем выгоднее это нам выйдет впоследствии. День жестянщика, одним словом.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
IT>>При чём тут вообще IT? Я с тобой не согласен, вот и всё. И не телько я.
E>Я и перечислил тех, кто не согласен.
Это ты перечислил тех, кого на поттасовках в вопросах не так просто провести.
E>Не буду говорить за vdimas, а у нас ситуация такая, что заказчиков слишком много, так как предлагаемые нами продукты и сервисы сейчас очень востребованны. Чем больше сможем удовлетворить сейчас, тем выгоднее это нам выйдет впоследствии. День жестянщика, одним словом.
И ты думаешь, что такая ситуация в вашей конторе даёт тебе право экстраполировать её на всю индустрию?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, eao197, Вы писали:
IT>>>При чём тут вообще IT? Я с тобой не согласен, вот и всё. И не телько я.
E>>Я и перечислил тех, кто не согласен.
IT>Это ты перечислил тех, кого на поттасовках в вопросах не так просто провести.
Если имелись в виду подтасовки, то мне за вами здесь просто не угнаться. Ваш проффесионализм в демагогии не оставляет никому шансов даже на спокойное ведение дискусии.
E>>Не буду говорить за vdimas, а у нас ситуация такая, что заказчиков слишком много, так как предлагаемые нами продукты и сервисы сейчас очень востребованны. Чем больше сможем удовлетворить сейчас, тем выгоднее это нам выйдет впоследствии. День жестянщика, одним словом.
IT>И ты думаешь, что такая ситуация в вашей конторе даёт тебе право экстраполировать её на всю индустрию?
А ты думаешь, что ваш опыт дает вам право экстраполировать его на всю индустрию?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>У меня в 2003-м был случай -- в четверг на наше руководство вышел заказчик с просьбой выполнить в буквальном смысле "горящий" заказ -- небольшую коммуникационную программу, которую нужно было запустить в боевую эксплуатацию на следующей неделе в среду. Т.е. во вторник она должна была быть полностью протестирована заказчиком, а в понедельник -- нами самими. В пятницу меня вызвали в Москву для решения этой проблемы. Выходные ушли на разработку, в понедельник к вечеру все было готово и протестировано, во вторник проверен весь комплекс, в среду все заработало. А по хорошему, там было на неделю спокойной размеренной работы с 9 до 18.
Здравствуйте, eao197, Вы писали:
IT>>Это ты перечислил тех, кого на поттасовках в вопросах не так просто провести.
E>Если имелись в виду подтасовки, то мне за вами здесь просто не угнаться. Ваш проффесионализм в демагогии не оставляет никому шансов даже на спокойное ведение дискусии.
Признайся, это ты со зла.
IT>>И ты думаешь, что такая ситуация в вашей конторе даёт тебе право экстраполировать её на всю индустрию?
E>А ты думаешь, что ваш опыт дает вам право экстраполировать его на всю индустрию?
Опыт вообще не даёт никаких прав никому. Опыт — это консистенция отрицательных зарядов... точнее разрядов. Т.е. это знание как не надо делать в определённой ситуации. Знания как надо делать в любой ситуации опыт не даёт. Другими словами, с опытом мы вычёркиваем заведомо неправильные решения, но выбор правильных всё равно приходится делать снова и снова.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали: V>Специфика многомерных задач, ИМХО. Не секрет, что строители проси..ают сроки гораздо реже разработчиков ПО.
Не знаю, где есть такой несекрет. У нас в Новосибирске и окрестностях окончание стройки в пределах запланированного срока бывает очень редко.
V> Не думаю, что строители гораздо умнее разработчиков, дело в многомерности задач. Для строителя не природный форс-мажор — это, например, закрылся завод поставщика, а другие производители не смогли вовремя его заменить из-за уже расписанных поставок.
Для строителя форс-мажор — это сперли больше утеплителя, чем незаметно, и надо заказывать новый. Это джумшуды, которые поставили стенку с уклоном больше 15% от вертикали, и ее теперь надо разбирать. Неучет того, что при данной температуре стяжка пола схватывается в полтора раза медленнее и задерживает выполнение штукатурных работ, а потом из-за низкой влажности она трескается и ее надо ремонтировать.
В итоге, к примеру, супермаркет МЕГАС сдали с опозданием на три месяца (а он строился в зоне жестких ограничений на долгострой и компанией, у которой хотя бы с деньгами всё в порядке), типичная же ошибка планирования — 3-4 квартала. Наверное, у нас более многомерное строительство?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали: E>У бухгалтеров, например, при завершении кварталов и финансового года. То же, кстати, специфика работы
Не у всех, знаешь ли, не у всех.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Специфика многомерных задач, ИМХО. Не секрет, что строители проси..ают сроки гораздо реже разработчиков ПО. S>Не знаю, где есть такой несекрет. У нас в Новосибирске и окрестностях окончание стройки в пределах запланированного срока бывает очень редко.
Вообще-то странно такое читать. У нас я слышал о случаях задержки сдачи домов только в ситуации, когда все квартиры уже раскуплены. А если дома строятся на рынок, то никаких задержек, причём — достоверная информация из первых рук.
Мания величия — это у нас профессиональное. 
* thriving in a production environment *
Если нам не помогут, то мы тоже никого не пощадим.
Может тебе везло? Может ты в стартапах не работал? Тебе виднее.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Мы уже победили, просто это еще не так заметно...
