Здравствуйте, AndrewVK, Вы писали:

E>>Ну и кроме того, программирование таки позволяет очень серьезно сжимать сроки, если это нужно.

AVK>Ты заблуждаешься. Авралить можно точно так же почти в любом виде инженерной деятельности. С точнотакими же последствиями.

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

AVK>>>Вот именно. И не надо валить на программирование.

E>>Тогда что в твоем понимании программирование -- только написание и компилирование программ?

AVK>В моем понимании программирование это прежде всего техническая дисциплина. И уж понятие о risk management в него точно не входит.

С этого нужно было начинать.

Здравствуйте, eao197, Вы писали:

E>Программирование -- это не чистая инженерная деятельность, но еще и производство.

Сути дела это не меняет.

E>Попробуй, например, во время ремонта стяжку на пол положить, и не дать ей просохнуть отведенное время.

Ха, такое сплошь и рядом.

E> А в программировании можно прогнать unit-тесты и сразу же программу в боевую эксплуатацию, под реальную нагрузку.

И что? В программировании можно вообще юнит-тесты не прогонять. При чем тут авралы?

E> А можно и вообще без тестов, есть и такие программисты.

И есть такие заказчики, которые за них не хотят платить.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, eao197, Вы писали:

E>>Программирование -- это не чистая инженерная деятельность, но еще и производство.

AVK>Сути дела это не меняет.

Ну ни херасе...

E>>Попробуй, например, во время ремонта стяжку на пол положить, и не дать ей просохнуть отведенное время.

AVK>Ха, такое сплошь и рядом.

И что, потом хороший пол получается?

E>> А в программировании можно прогнать unit-тесты и сразу же программу в боевую эксплуатацию, под реальную нагрузку.

AVK>И что? В программировании можно вообще юнит-тесты не прогонять. При чем тут авралы?

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

Здравствуйте, eao197, Вы писали:

E>>>Программирование -- это не чистая инженерная деятельность, но еще и производство.

AVK>>Сути дела это не меняет.

E>Ну ни херасе...

Во-первых осторожнее с выражениями, во-вторых на производстве, если это не конывеер, авралы очень даже приключаются.

AVK>>Ха, такое сплошь и рядом.

E>И что, потом хороший пол получается?

Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.

AVK>>И что? В программировании можно вообще юнит-тесты не прогонять. При чем тут авралы?

E>При том, что в программировании не соблюдение технологии и/или нормального расписания работы все равно способно приводить к качественным результатам.

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

E> Что позволяет выправлять различные огрехи (менеджеров или программистов) или форс-мажоры с помощью сверхурочной работы.

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

Здравствуйте, AndrewVK, Вы писали:

E>>>>Программирование -- это не чистая инженерная деятельность, но еще и производство.

AVK>>>Сути дела это не меняет.

E>>Ну ни херасе...

AVK>Во-первых осторожнее с выражениями, во-вторых на производстве, если это не конывеер, авралы очень даже приключаются.

У бухгалтеров, например, при завершении кварталов и финансового года. То же, кстати, специфика работы

AVK>>>Ха, такое сплошь и рядом.

E>>И что, потом хороший пол получается?

AVK>Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.

А где я говорил, что авралы обязательно длительные?
Про регулярность авралов говорил, помню. А вот про длительность?

AVK>>>И что? В программировании можно вообще юнит-тесты не прогонять. При чем тут авралы?

E>>При том, что в программировании не соблюдение технологии и/или нормального расписания работы все равно способно приводить к качественным результатам.

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

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

E>> Что позволяет выправлять различные огрехи (менеджеров или программистов) или форс-мажоры с помощью сверхурочной работы.

AVK>В более менее долгой перспективе ни к чему это, окромя лишних багов, не приводит.

Опять же я не говорил о долгой перспективе.
Хотя я знаю примеры довольно крупных контор, в которых в разрабатываемых годами проектах время от времени устраивают bug hunting day, да еще в выходной. Аврал? Аврал, но он же не длится месяцами время. И мироощущение разработчиков/тестировщиков там никого не интересует -- ты либо работаешь, либо идешь против корпоративных правил.

Здравствуйте, eao197, Вы писали:

E>Интересно, откуда взялось "хоть раз"? В голосовании я спрашивал про "авралы", во множественном числе.
Ты спрашивал про единичные авралы, а не систематические.

E>Как раз сейчас предстоит участвовать в проекте, срок реализации которого был сокращен с 4-х месяцев до 3-х.
Ну и сами себе кузнецы...

Здравствуйте, AndrewVK, Вы писали:

AVK>А что, при программировании ночами и выходными длительное время получается хороший софт.

Ну, по моему ИМХО, авралы принципиально не могут длиться более недели, иначе действительно надо согласовывать новые сроки. Аврал оправдан только тогда, когда в результате укладываемся в какой-нить deadline (плюс/минус пару дней), что есть несомненный плюс. А после аврала запросто можно дать пару лишних выходных.

Здравствуйте, eao197, Вы писали:

E>У бухгалтеров, например, при завершении кварталов и финансового года. То же, кстати, специфика работы

Когда у всех вокруг одна и та же специфика, то это уже не специфика.

AVK>>Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.

E>А где я говорил, что авралы обязательно длительные?
E>Про регулярность авралов говорил, помню. А вот про длительность?

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

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

E>Тем не менее, чем серьезнее ПО, тем более формальный процесс разработки.

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

AVK>>В более менее долгой перспективе ни к чему это, окромя лишних багов, не приводит.

E>Опять же я не говорил о долгой перспективе.

Регулярные авралы это и есть долгая перспектива.

E>Хотя я знаю примеры довольно крупных контор, в которых в разрабатываемых годами проектах время от времени устраивают bug hunting day, да еще в выходной.

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

E>И мироощущение разработчиков/тестировщиков там никого не интересует -- ты либо работаешь, либо идешь против корпоративных правил.

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

Здравствуйте, vdimas, Вы писали:

AVK>>А что, при программировании ночами и выходными длительное время получается хороший софт.

V>Ну, по моему ИМХО, авралы принципиально не могут длиться более недели

Дело не в том, сколько длится конкретный аврал, дело в том насколько аврал является обычным явлением.

V>Аврал оправдан только тогда, когда в результате укладываемся в какой-нить deadline (плюс/минус пару дней), что есть несомненный плюс.

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

V> А после аврала запросто можно дать пару лишних выходных.

Смешно.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, eao197, Вы писали:

E>>Интересно, откуда взялось "хоть раз"? В голосовании я спрашивал про "авралы", во множественном числе.
IB>Ты спрашивал про единичные авралы, а не систематические.

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

Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме.

Здравствуйте, AndrewVK, Вы писали:

E>>У бухгалтеров, например, при завершении кварталов и финансового года. То же, кстати, специфика работы

AVK>Когда у всех вокруг одна и та же специфика, то это уже не специфика.

Еще раз повторюсь, я утверждал, что авралы -- это только часть специфики программирования.

AVK>>>Плохой конечно. А что, при программировании ночами и выходными длительное время получается хороший софт.

E>>А где я говорил, что авралы обязательно длительные?
E>>Про регулярность авралов говорил, помню. А вот про длительность?

AVK>А регулярные авралы это и есть длительный период.

Ну ничего подобного. За прошедший год я отработал только 7 или 8 выходных и мой рабочий день очень редко превышал 8 часов. Да, отрабатывать в выходные приходилось регулярно, с периодом в 3-4 месяца. Но вот длительности авралов я здесь не вижу в упор.

AVK>>>В более менее долгой перспективе ни к чему это, окромя лишних багов, не приводит.

E>>Опять же я не говорил о долгой перспективе.

AVK>Регулярные авралы это и есть долгая перспектива.

Ага, длиною в жизнь, надо полагать.

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

Т.е. shit happens. Вопрос только в везении втоптаться или не втоптаться в него. И если кто-то еще не втоптался, то это пока всего лишь вопрос времени.

Здравствуйте, eao197, Вы писали:

E>Во-первых, где в моем вопросе было упоминание "единичных" или "хотя бы один"?
В твоем вопросе не было "систематических" или "регулярных".

E>Во-вторых, если у двадцати человек за последние пять лет в разных проектах было более одного аврала (вспоминаем про множественное число), то это уже система.
Система — это если бы у всех были регулярные авралы.
А так, вы просто рвете на себе рубаху и занимаетесь нездоровым мазохизмом.

E>Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме.
Это не мы в белом, это... Ну ты понял..

Здравствуйте, IB, Вы писали:

E>>Во-вторых, если у двадцати человек за последние пять лет в разных проектах было более одного аврала (вспоминаем про множественное число), то это уже система.
IB>Система — это если бы у всех были регулярные авралы.

Это была бы уже другая система, которая показала бы, что дела в разработке ПО вообще швах.

E>>Конечно, монстры RSDN в лице IB, AVK, IT и VladD2 -- все в белом, у них все путем, вокруг правда все в дерьме.
IB>Это не мы в белом, это... Ну ты понял..

Да, точно как в притче:

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

Мораль: не тот враг, кто тебя в дерьмо посадил, и не тот друг, кто тебя из дерьма вытащил, а если тебе тепло и хорошо -- то сиди тихо и не чирикай.

А вот я что-то расчирикался. Того и гляди ща раскопают и сожрут.

Здравствуйте, eao197, Вы писали:

E>Это была бы уже другая система, которая показала бы, что дела в разработке ПО вообще швах.
Нету никакой системы, есть лишь криворукие менеджеры и безответственные или самоотверженные разработчики...


E>Да, точно как в притче:
Угу. Если тебе с авралами тепло и хорошо, то не пеняй на всю разработку..

Здравствуйте, IB, Вы писали:

E>>Это была бы уже другая система, которая показала бы, что дела в разработке ПО вообще швах.
IB>Нету никакой системы, есть лишь криворукие менеджеры и безответственные или самоотверженные разработчики...

И этот факт, естественно, никоим боком к специфике программирования не относится.

Здравствуйте, eao197, Вы писали:

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

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, eao197, Вы писали:

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

А! Я понял! Программирование -- это написание кода в редакторе/IDE, компиляция и, может быть, чуть-чуть потестировать-поотлаживать!

Я-то думал, что это значит взять задачу, решить и сдать заказчику. Со всеми заморочками.

Каюсь, не знал! Так бы помер и не узнал бы

Всем спасибо за науку
Тему можно закрывать и сносить в "Мусор".

Здравствуйте, eao197, Вы писали:

AVK>>Когда у всех вокруг одна и та же специфика, то это уже не специфика.

E>Еще раз повторюсь, я утверждал, что авралы -- это только часть специфики программирования.

Это что то меняет?

AVK>>А регулярные авралы это и есть длительный период.

E>Ну ничего подобного. За прошедший год я отработал только 7 или 8 выходных

Это много, это порядка 9% от оставшихся выходных. Впрочем, что то я тебя не пойму. Ты же сам утверждал что авралы у тебя регулярные.

E> и мой рабочий день очень редко превышал 8 часов. Да, отрабатывать в выходные приходилось регулярно, с периодом в 3-4 месяца. Но вот длительности авралов я здесь не вижу в упор.

Ты уж определись — либо авралы у тебя случаются регулярно, либо это исключительная ситуация.

E>Т.е. shit happens. Вопрос только в везении втоптаться или не втоптаться в него.

Нет, везение тут не при чем.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, eao197, Вы писали:

AVK>>>Когда у всех вокруг одна и та же специфика, то это уже не специфика.

E>>Еще раз повторюсь, я утверждал, что авралы -- это только часть специфики программирования.

AVK>Это что то меняет?

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

AVK>>>А регулярные авралы это и есть длительный период.

E>>Ну ничего подобного. За прошедший год я отработал только 7 или 8 выходных

AVK>Это много, это порядка 9% от оставшихся выходных. Впрочем, что то я тебя не пойму. Ты же сам утверждал что авралы у тебя регулярные.

E>> и мой рабочий день очень редко превышал 8 часов. Да, отрабатывать в выходные приходилось регулярно, с периодом в 3-4 месяца. Но вот длительности авралов я здесь не вижу в упор.

AVK>Ты уж определись — либо авралы у тебя случаются регулярно, либо это исключительная ситуация.

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

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

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

Здравствуйте, eao197, Вы писали:

E>Только то, что авралы могут быть и частью специфики в других профессиях. Более того, человеческий фактор, наверное, везде одна из самых главных причин авралов.

Я там определение слова специфика уже приводил.

AVK>>Ты уж определись — либо авралы у тебя случаются регулярно, либо это исключительная ситуация.

E>Регулярность и длительность -- это разные вещи. Да, переработки в виде одного-двух выходных на работе встречаются регулярно

Ну и не о чем тогда говорить.