Неправильное планирование :-) Если быть точнее, то всему виной слишком общая постановка задачи. Что бы хоть как-то (+-)10% соблюсти сроки нужно брать в команду не программистов а кодеров, которые переводят в понимаемый компилятором язык то, что написано постановщиком. То есть задание не должно содержать ничего, что требовало бы работы по поиску (разработке) алгоритма реализуемой части. то есть постановка задачи должна быть программой но не на языке программирования.

Да и за время разработки продукта от полугода до N лет (допустим планирование было идеальным и разработчик тоже) меняется среда в которой этой программе нужно работать.

Добрый день! Присоединяясь к уже сказанному выше, добавлю следущее.

Несмотря на "раскрученность", профессия программиста в сравнении с другими инженерными профессиями - младенческая. Многие копья, которые ломаются ныне в soft-среде, в иных отраслях были уже сломаны лет 150 назад, а лет 120 назад заменены на пистолеты.

Например,

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

Как сказал кто-то умный Биллу Гейтсу: "Если бы проектирование и производство автомобилей происходило столь же неаккуратно, как создание программного обеспечения, то автомобили беспричинно "зависали" бы каждый день, а при переключении скоростей глохли бы и предлагали перезапустить двигатель или обратиться в сервис-центр".

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

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

С искренним уважением,

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

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

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

Этой репликой я лишь хотел сказать, что отрасль программирования несомнненно продвинулась в сторону качества, если бы срок жизни среды в которой работает программа (ОС, железо, прикладное окружение) остановилось бы в своем развитии хотябы лет на 10.

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

Ну и 10 лет назад "программисты" не занимались поддержкой пользователей и не покупали компьютеры. Просто слишком многих людей стали называть программистами. Словом программист называют ЛЮБОГО кто не набивает на компьютере накладные или договора.

Гарантии всегда даются при определенных условиях. Но они должны даваться и тем более соблюдаться. Прозрачность это неотъемлемая часть качества. (не стоит путать прозрачность с открытостью)

День добрый!

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

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

Я же писал о другом. Об отношении к сложным задачам.

Когда мост падает, для инженера - это зачастую личная драма. Даже, если никто не пострадал.

Когда "ломается софт", для многих (увы!) программистов - это "совершенно естественно".

Условно говоря имеем мин. две позиции:

а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"

     (Позиция 1)

б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".

     (Позиция 2)

Согласитесь, есть разница.

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

Уважаемый, Сергей!  Это не так. Мосты, построенные в соответствующем регионе должны соответствовать определенному стандарту. И если их смыло, то и проектировщики, и строители за это ответили. Всякий раз назначается расследование и все, что необходимо.

С Уважением,

День добрый!

Когда мост падает, для инженера - это зачастую личная драма. Даже, если никто не пострадал.

и программисты такие есть

Когда "ломается софт", для многих (увы!) программистов - это "совершенно естественно"

и такие наверно есть

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

наплевательское отношение к работе свойственно не только программистам.

Условно говоря имеем мин. две позиции:

а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"

     (Позиция 1)

он нигде долго не протянет

б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".

     (Позиция 2)

Согласитесь, есть разница.

Естественно есть. Вторая выигрышней не только для программистов.

Уважаемый, Сергей!  Это не так. Мосты, построенные в соответствующем регионе должны соответствовать определенному стандарту. И если их смыло, то и проектировщики, и строители за это ответили. Всякий раз назначается расследование и все, что необходимо.

Ну да :-) и срок дадут за некачественную работу выразившуюся в растрате понапрасну материальных средств государства. Да я бы сразу уехал из такого государства. При чем тут инженер? Откуда он знал что в районе за N км от моря на обычный мост выльется N тонн морской воды? Выговор - максимальное наказание если оно вообще будет. И было бы странно иное.

В ЛЮБЫХ профессиях есть трудяги и халтурщики, каждый день мы с этим сталкиваемся, но почему-то программистов некоторые люди априори считают халтурщиками. Наверно уже пора проводить среди народа разъяснительную работу, что бы слово "программист" не ассоциировалось у них с мальчиком который к ним подбегает, либо с техником, обслуживающим компьютеры.

Еще раз, день добрый!

> вторая выигрышней не только для программистов

>и программисты такие есть

Конечно, и я даже таких знаю :-).

Далее, как мне кажется, для добросовестных программистов профессионально важно активно пропагандировать/рекламировать позицию 2 и "отстраиваться" от тех, кто занимает позицию 1.

(Пока последних, к несчастью, больше и они действительно "портят рынок").

>В ЛЮБЫХ профессиях есть трудяги и халтурщики, каждый день мы с этим сталкиваемся, но почему-то >программистов некоторые люди априори считают халтурщиками (...)

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

>Ну да :-) и срок дадут за некачественную работу выразившуюся в растрате понапрасну материальных средств >государства (...) При чем тут инженер? Откуда он знал что в районе за N км от моря на обычный мост выльется >N тонн морской воды?

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

>Да я бы сразу уехал из такого государства...

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

С пожеланием сильных решений!

Там мосты снесло водой, которую тайфунчики прибрежные на _сушу_ вылили, и дофига вылили, они по пути там еще че-то с собой прихватили. Этим потоком и посносило ВСЕ что было плохо построено. В любом случае это было стихийное бедствие без всяких придирок и никто не станет обвинять инженеров строивших мосты за 100 км от воды.

 Даже и не в сейсмозоне, а в обычном городе, если дом будет построен с нарушением соответствующих СНиП'ов - это может очень дорого обойтись.

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

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

Есть программисты которые пишут ПО для спутников и медицинских приборов. Я думаю у них с нормами морали и ответственности наверно порядок. (Хотя слышал один американский спутник таки исчез из-за программера :-) Наверно его оштрафовали :-)

Цитата:

> (...) это надо чтоб пара микрорайонов одновременно рухнула, вот

> тогда им может строгача и ввалят.

Это не так.

>(Хотя слышал один американский спутник таки исчез из-за >программера :-) Наверно его оштрафовали :-)

Я думаю это, как раз, одна из баек придуманная для оправдания слабости. По крайней мере, я таких слышал уже штук 7 (про спутник, утонувший корабль, потерявшуюся ракету и т.п.).

Постоянные байки про неудачников не возвышают имидж профессии.

А вот легенды про программера своим решением спасшего (пусть не спутник), но хоть, что-нибудь значимое что-то давно не слыхать. Хотя фактура наверняка есть.

С Уважением,

Сравнивая процесс программирования с процессом конструирования моста, я бы хотел отметить одну особенность:

Допустим, строительство моста состоит из следующих фаз:

- Разработка проекта (3 человеко-месяца)

- Сборка конструкции по проекту (40 человеко-месяцев)

Если попытаться найти прямую аналогию, то разработка программы состоит из таких же фаз:

- Разработка проекта (описание того, что надо сделать на языке программирования) (3 человеко-месяца)

- Сборка собственно программы (компиляция) (практически мгновенно).

Отсюда можно сделать два вывода:

1) Сравнивать мост, над которым работали 20 рабочих два месяца надо с программой, которую один программист делает три месяца (это достаточно небольшой проект). Код Windows надо сравнивать не иначе как с конструкциями всех автомобилей за все времена.

2) "Бесплатный" этап сборки ПО дает программистам свободу пробовать свой проект сразу после написания. Оборотной стороной этого является беспечность.

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

По поводу плохих и хороших программистов и создания проектов.

Мне кажется, что 50% вины за несвоевременно или неправильно сделанный проект, который к тому же не уложился в бюджет - это вина начальства фирмы, для которой это все делается. Почему? Да потому, что обычно хочется много всего за небольшие деньги и быстро. А по мере продвижения проекта вдруг оказывается, что много-много чего не предусмотрели, забыли, придумали - вот она, дополнительная функциональность, переделка уже сделанного и т.д. и т.п. Опять же, за небольшие деньги кого наймешь? Правильно, программистов из пункта 1 (см. выше). На пункт 2 не хватает маней :) Результат следует очевидный - если чего и сделано, то ужас как.

Это конечно все в кратце.......

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

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

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

Извиняюсь за сумбурность, что-то сегодня мысли вперемешку ходят :))

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

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

Правда, я бы эту цепочку изложил чуть иначе: "Архитектор - Технолог - Кодер", либо "Архитектор - Технолог - Кодер - Контролер" (думаю лет через 7 такая модель станет привычной). То есть, программирование в своем развитии те же этапы, что и другие специальности.

Я также внимательно перечитал свои сообщения и не обнаружил там "желания обвинить всех", да и вообще желания "обвинить".

Я просто изложил факты:

Факт 1: "Ошибок в программном обеспечении очень много"

Факт 2: "Есть разделяемая многими (но не всеми) "теория" о том, что наличие ошибок это нормально. Эта "теория" временная.

Факт 3: "Есть альтернативная точка зрения. И она более продуктивна".

Факт 4: "В иных отраслях аналогичные споры уже были.

Например, в медицине спор о качестве качестве работы врача и о его ответственности был актуален в 1820-30-е годы. (При этом, я хотел бы обратить Ваше внимание на тот факт, что не только весь организм человека, но большинство органов - это более сложные и по сей день менее понятные системы, чем Windows). В начале 19 века считалось, что "раз человек так сложен", то, когда он умирает в больнице - это совершенно нормально. Если выжил - это победа врача, если умер - так угодно богу. См., например, статью "Победа для побежденных".

С Уважением,

На мой взгляд, пусть частичные, но продуктивные ответы дал Кирилл Лебедев:

• Распространенный прием создания ошибки. Часть 1
• Распространенный прием создания ошибки. Часть 2
• Три шага к ошибке

С Уважением,

Добрый день, Сергей!

> Вопросы качества проекта для инженеров (не программистов) -

> это давно вопросы чести. Инженер -строитель после возведения

> моста по его проекту становится под мост и по мосту едет

> товарный поезд

Честно говоря, ни разу не слышал о таком в наши дни, а только читал в исторических книгах. Но допустим, что это так.

> а средне-статистический программист утверждает: "Техника

> сложна. Ошибки всегда будут. За работоспособность программы

> (мной же написанной) я отвечать не хочу".

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

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

Ближайшая аналогий - производство лекарств. Новые препараты тщательно тестируют, проверяют и перепроверяют по 3-5-7 лет (сравните со сроками тестирования средней программы!!!), и всё равно - из 100,000 человек, выпивших лекарство, на 99900 человек оно действует, как было запланировано, на 90 не действует вообще, а 10 попадают в больницу из-за побочных эффектов.

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

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

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

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

> Простая фраза "Писать программы без брака" - сегодня могла

> бы стать миссией для любой софт-фирмы).

Если бы была выполнимой.

> И еще. Если лет 10 назад слово "программист" у большинства

> руководителей компаний вызывало стереотип "кого-то очень

> умного и непостижимого, творящего великие программные

> продукты", то сейчас все чаще и чаще стереотип "кого-то очень

> понятного, ленивого, вечно увольняющегося, не доделывающего

> проект, ворующего по мелкому комплектующие и получающего

> чаевые в компьютерных фирмах".

Таких просто не надо брать на работу. Радикальное такое лекарство :)

Уважаемый Александр!

>И если мост должен выполнять одну-единственную операцию стоять...

а) Данная функция сформулирована Вами неверно.

б) Мост выполняет несколько сотен функций.

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

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

Вы в своем сообщении делаете ряд длинных выводов, основываясь на ошибочных тезисах (некоторые из них выше).

>Возникает такое количество комбинаций, которое человек просто не может охватить умом...

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

>Честно говоря, ни разу не слышал о таком в наши дни, а только

>читал в исторических книгах...

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

Вообще есть еще много чего такого о чем Вы не слышали.  Всех благ,

Александр!

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

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

Я очень согласен с Сергеем Сычевым, который написал: "(...) имеем мин. две позиции:

а) "Вот есть сложная система и поэтому (серия примеров и аргументов) я ни за что не хочу ручаться"

     (Позиция 1)

б) "Да, эта система сложна, но я приложу максимум усилий, чтобы она работала стабильно. И в этом (кроме прочего) заключается моя профессиональная гордость".

     (Позиция 2)

Эти две позиции мы имеем и в данном обсуждении: есть коллеги, которые отстаивают Позицию 1. В частности, Ваша серия примеров и аргументов направлена на ее защиту.

А есть коллеги, которые защищают Позицию 2. Есть даже коллеги, которые не только защищают эту Позицию, но и разрабатывают методику "по сокращению ошибок" (например, Кирилл Лебедев). И кредит доверия к таким коллегам гораздо выше

>> Простая фраза "Писать программы без брака" - сегодня могла
>> бы стать миссией для любой софт-фирмы).

>Если бы была выполнимой

Мне кажется коллегам, которые поддерживают Позицию 2 полезно было бы подумать над работой, которую можно было бы назвать (условно): "Работа над ошибками". Можно ведь сколько угодно спорить о сложности мира, а можно решать задачи.

>Таких просто не надо брать на работу. Радикальное такое лекарство :)

Не надо менять тезис. Речь шла о том, что имидж профессии "программист" снижается. Это, к сожалению, имеет место быть.

С уважением,

Редакция присоединяется к позиции Георгия Соколова, а также благодарит Михаила Опанасенко за призыв к "Работе над ошибками".

С Уважением,

> Вы описали "аварийные взаимоотношения с Заказчиком", который

> меняет правила во время игры.

В той или иной степени это происходит с каждым существенным проектом в области ПО.

>Я очень согласен с Сергеем Сычевым, который написал: "(...)

>имеем мин. две позиции:

>(Позиция 1)

>а) "Вот есть сложная система и поэтому (серия примеров и

>аргументов) я ни за что не хочу ручаться"

>(Позиция 2)

>б) "Да, эта система сложна, но я приложу максимум усилий, чтобы

>она работала стабильно. И в этом (кроме прочего) заключается

>моя профессиональная гордость"

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

Покажите мне хоть одну серьёзную программу, которая никогда не сбоит - и я встану на Вашу сторону. А до тех пор - увы.

>Не надо менять тезис. Речь шла о том, что имидж профессии

>"программист" снижается. Это, к сожалению, имеет место быть

А почему "к сожалению"? Совершенно нормальное явление. Сравните в этом плане профессию программиста с профессией шофера или летчика. Или даже с профессией космонавта. Гагарина знал весь мир. А кто там сегодня на орбите болтается, Вы помните?

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

Снижение имиджа в таких условиях предсказуемо и неизбежно. И вовсе не из-за качества работы.

>б) Мост выполняет несколько сотен функций.

Приведите хотя бы 5, пожалуйста.

>в) Пароход (тем более, самолет) спроектировать и

>построить труднее, чем написать большую часть

>программ, написанных человечеством за последний

>год.

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

>Моя ответственность только за то, что находиться

>в области моего влияния. Как Вася может себя обвинять

>в том, что мост рухнул из-за слишком тяжелого поезда

>если:

>
>1. Он не регулирует движением поездов.
>2. Не вел рассчеты моста.
>3. Вообще ничего не делал кроме ответственной работы замешивания бетона?

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

>Разумно. Но бывает, что области влияния программиста на программу хватает, чтобы исправить некоторые конструктивные недостатки. Поэтому часто полезно себя спрашивать: "Все ли я сделал для того, чтобы предотвратить этот недостаток?"

Дык получается, что я еще и должен искать какие-то другие недостатки за других людей? Ну, загнул ты, батенька, тут бы свое понять :)

>Программисту приходится работать в противоречивых условиях: с одной стороны давлеют требования качества, с другой - ограничения по времени. Но я замечал, что наиболее качественные решения появляются именно тогда, когда соблюдается как первое, так и второе решения. Как говорится: "Необходимость обостряет разум".

А может все же правильнее вот это высказывание: Спешка важно только при ловле блох ?

>Существует 2 подхода:
>1. Дайте мне больше ресурсов (времени, денег), и я вам напишу качественную программу.
>2. Я умею писать программы вот такого высокого качества. Если вас это заинтересует, то мне для работы нужны такие-то и такие-то ресурсы.

>Второй подход, на мой взгляд, эффективнее, т.к. он не является голословным.

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

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

Так что с кем спорите по поводу надуманных подходов - хотя никто тут за первый не ратовал - я чего-то не пойму

Предлагаю сформулировать принципы на базе которой можно

прийти к соглашению

  1. В каждом деле существуют сложные проекты,

     существуют задачи, охватить которые человек

     не в состоянии

  2. В области разработки ПО есть специфика, связанная с

     со скоростью модификации как постановки задачи, так и

     со временем реализации

  3. Каждый серьезный профессионал должен нести отвественность

     (в т.ч. моральную) за качество своей работы

  4. В любом сложном проекте ошибки неизбежны, как по вине
      разработчика, та и по независимым от него причинам

  5. Разработчик должен стремиться к ликвидации ошибок,

      как своих, так и не зависящих от него

  6. Одним из путей уменьшения числа ошибок является

      создание и развитие специальных, технологий,

      повышающих надежность и качество разработки.

  Думаю, эти пункты не вызовут возражений у участников форума

Уважаемый Кирилл! Благодарю Вас за конкретные предложения по устранению ряда ошибок (пока Вы единственный из участников обсуждения, кто это сделал).

Буду рад, если Вам поможет (для развития методики по сокращению ошибок программирования) предложение ввести понятие "уровни ошибок". Я приведу примеры, а потом поясню зачем.

4 уровня ошибок (не настаиваю именно на таком разделении, но мне важен пример).

Уровень 1. Ошибки, причиной которых является простая неаккуратность, неорганизованность...

Примеров множество в любой отрасли.

Уровень 2. Например, такие ошибки, которые описаны в Ваших статьях:

http://www.homepc.ru/doityourself/22457/
http://www.homepc.ru/doityourself/22598/
http://www.homepc.ru/doityourself/22697/
http://www.homepc.ru/school/22854/

Ваш Пример. "Ступенчатый метод" (или слишком длинная цепочка делегирования)

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

Ваш Пример. Перенос части кода из одного фрагмента в другой. Создание нового документа/кода на основе копии старого.

Аналоги за пределами программирования. Их множество. Вот простейший: делопроизводитель создает договор на основе другого договора и создает ошибки. Затем данные ошибки тиражируются, если на основании этих документов, создаются вторичные документы. Скажем в договоре в силу подобного "переноса" образовалась ошибка в реквизитах, как следствие: создали платежку с неверными реквизитами и отправили деньги на другой счет. И т.п.

Ваш Пример. Вынесение типового кода в библиотеку и последующие перенос в др. надсистему без учета ее контекста.

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

Еще пример. Здесь на Форуме Георгий Соколов цитировал своего преподавателя по мат. лингвистике профессора Тузова: "В русском языке "разбить" можно: сквер, палатку, вазу и морду".

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

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

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

Уровень 3. Ошибки архитектуры (т.е., заложенные при проектировании) и/или неучет технологии

Например,

3.1. Просто нерациональность архитектуры

3.2. Неучет масштаба проекта при проектировании. Или на малом числе операций, записей в базе и т.д. все работает нормально, а на большом - нет.

3.3. Неучет "возрастания разнородности" многочисленных объектов, запросов, взаимодействий при увеличении проекта.

3.4. То же "в обратную сторону" (на малом проекте и мощной машине, на котором он создавался - все ОК), а при росте проекта память расходуется избыточно.

3.5. ..... и т.д. ....

3.N. Иное

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

Скорее всего, говоря о 4-м уровне, мы, в ряде случаев, уже должны не использовать слово "ошибка", а должны использовать слово "задача".

----------------------------------------------------

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

Более важны:

А. Само разделение всех разнообразных ошибок по разным "весовым" качественным уровням.
В. Учет того обстоятельства, что (предположительно) профилактические средства от ошибок на каждом уровни будут свои.

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

Эта статистика за годы работы (подчеркну с разными проектами, и с разными программистами) свидетельствует: не менее 80% всех ошибок - это ошибки первого и второго уровней. Ошибки третьего уровня составляют не более 20%, а уж ошибки/задачи 4-го уровня - это вообще "штучный товар". (Даже за корректную формулировку подобных сверхзадач (не то, что за их решение) у нас можно получить премию).

И в таком контексте качественно меняется смысл разговора про выполнимость или невыполнимость миссии "писать без ошибок".

Аналогия за пределами программирования:

"В середине XIX века в Европе при родах от родильной лихорадки умирало не менее 20% рожениц. (А в иных клиниках эта цифра доходила до 50%). К сожалению, большинство врачей считало это вполне нормальным явлением. По их мнению, женщины погибали от «атмосферно-космической» эпидемии, вызываемой невидимыми «миазмами», борьба с которыми совершенно безнадежна. Разумеется, не было недостатка в разговорах о до конца непостижимой сложности организма и многофакторности, которую
умом не охватить и т.д., и т.п.".

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

В знак протеста "обиженные" врачи упекли Земмельвейса в сумасшедший дом.

Однако, в тех клиниках, где это стали делать смертность действительно упала (с 20-ти до 2-х %) и впоследствие этот метод стал общепринятым и, как мы знаем, не только в роддоме.

Еще раз позвольте поблагодарить Вас полезную информацию.

С Уважением,

Согласно моей практике такое происходит не из-за слишком сжатых сроков разработки ПО, а из-за нетехнологичности процесса разработки.
Например, при работе над последним проектом я потратил:
1) 10 - 15 % времени только из-за отсутствия должной коммуникации с одним из программистов "команды". Поскольку ни одна моя попытка не позволила установить с ним контакт, мне пришлось разбираться в его коде самому. Самому находить его баги. И предпринимать не всегда верные шаги. Он мог потратить час на объяснение. И ничего бы не потребовалось.

У нас, к примеру, все работают в тесном коллективе, друг до друга идти пешком меньше пары минут.

2) 20 - 30 % времени мне пришлось потратить на поиск нужной информации, ее изучение и отсев ненужной. В том числе - не только в Интернете, но и внутри компании. Если бы в фирме был организован информационный портал, в котором бы излагался и предыдущий опыт, мои затраты значительно бы сократились.

Т.е. кто-то должен сначала потратить время, чтобы популяризовать проделанное командой программистов? :) Нет проблем и есть такие дяди, и есть их книги с прилагаемыми к ним носителями информации... Платите и пользуйтесь на здоровье. ;)

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

3) 20 - 30 % времени было потрачено из-за отсутствия технологии решения задач. Часто приходилось перебирать варианты, пытаться решить проблемы, которые не только не имели решения, но и которые-то решать не нужно было.

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

Итого: достаточно серьезные резервы для оптимизации по времени процесса разработки ПО.

Итого: резерва не видно, есть только рекомендация перед тем как приступить к собственно программированию следует разобраться в ТЗ.

> А в условиях наличия большого колличества контор выигрывает тот кто предложит самое дешевое и быстрое решение.

Проблема не в дешевизне проекта, а в нетехнологичности процесса получения заказа.

Отчего же. "Дешевые" (в обсуждаемых здесь терминах) коллективы программистов перехватывают заказ (составляют смету) еще до построения ТЗ...

Такая вот диалектика.

;)

Уважаемые коллеги! В этом контексте будут отображаться сообщения, касающиеся ошибок в программировании.

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

Уважаемые коллеги!

1) Справедливость требует признать, что часто действительно, как Пишет Кирилл Лебедев "Проблема не в дешевизне проекта, а в нетехнологичности процесса...".

2) О том, как люди обваливают работу - рассказано здесь:                                        

Успехов!

Safety Critical - это не повседневная задача - согласен.

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

это чистой воды обычная задача.

и при разбоке шаблонов поиска на AWK - тут никакой безопастностью и не пахнет

- рядовой синтаксический анализатор.

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

она на их сайте доступна лежит.

я научился на нем (на ихнем языке без использования метода) описывать базы данных под рсубд.

P.S.
это так отсебятина.

кризис в разработке софтвера был всегда.

в 83 году, когда я стал 41 (наверно я всех членов команды не знал)

членом команды по моделированию полетов самолета на os/360 про кризис уже трубили полным ходом.

а картинки из книги Вельбицкого до сих пор радуют глаз актуальностью.

(впрочем он их содрал еще откудато - что подчеркивет древнее происхождение кризиса)

это проблема борьбы со сложностью системы при больших задачах.

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

боже я такого не хотел постить.

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

по поводу классификации ошибок и предложений по их устранению я держал в руках отчет фирмы TRW "характеристики качества программного обеспечения" от некоего Боема. при ссср был издан в районе 85 года. точно не могу указать ссылку. сорри. в статье Прехельта (http://www.osp.ru/os/2000/12/045.htm) есть ссылка на Боема (3] B.W. Boehm, Software Engineering Economics, Prentice Hall, Englewood Cliffs, N.J., 1981 )

- по общим признакам я уверен - это тот же самый

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

V.S. Alagar, K.Periyasamy, Specification of Software Systems, Springer, 1998 -

обсуждает проблемы создания качественного по. рассматриваются Z, WDM, Larch/C++

>Ознакомившись с RSL видно , что

за два дня?

:))))))))))))))))

RSL - это одна из конструктивных математик

сравнить с "ознакомившись за два дня с матанализом". (явное влияние книжек типа

Оракл для занятых за 24 урока)
:))))))))))))))))))))))))))))

>1) Возможности его применения ограничены

>(Например, трудно применить в системах основанных на взаимодействии с
>пользователем),

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

>2) Использование не решит задачу создания качественного ПО.
>( С ошибками можно писать и на нем. Притом легко :-). )

:)))))))))

писать с ошибками легко можно на всем. тяжело компилировать потом. rsl позволяет писать кратко (меньше текста - меньше ошибок) и отлавливает больший
класс ошибок.


rsl - проработанная технология - именно технология повышает качество продукта
(конвеер), а не разговоры про совесть и ответственность разработчика.
------------

мысли уважаемого Лебедева про ступенчатый метод со сслыкой на Гамма Э., Хелм
Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования.

Паттерны проектирования. ? СПб.: Питер, 2001
проходят красной нитью через всю историю программирования. я их читал в
работах академика Глушкова за 1960 годы, например. отечественная P-технология
и RSL Development Method есть применение этих мыслей к жизни.

http://www.cs.iastate.edu/~leavens/larchc++.html

http://s3.informatik.uni-essen.de/publications/
http://www.cs.concordia.ca/htbin/fac_page.cgi?Alagar

:)

Добрый день! Вы пишите:

>для сокращения ошибок програмирования - главным подходом может быть только >сокращение числа строчек (операторов) получаемой программы - кол-во ошибок, >которые делает в тексте НЕ ЗАВИСИТ ОТ языка, на котором он пишет. это константа на >число строчек.

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

Спасибо за ссылки.

С Уважением,

>Пока я заметил немного другую закономерность: разные ошибки 1-2-го уровней могут >быть предотвращены/найдены с помощью мер разного уровня (...)

Где-то, я думаю, это начинает действовать начиная с 3-его уровня и выше. То есть, например, продуманной архитектурой (и не только) можно уменьшить количество кода при сохранении функций. Нет кода нет ошибок.

Могу прислать несколько примеров, если интересно.

С Уважением,

Для тех, кто еще не читал - веселенькая, хотя и старая ссылка к праздникам:-)

http://www.livejournal.com/talkpost.bml?journal=alconaft&itemid=602

Добрый вечер! Цитирую:

>1)Есть и другие младенческие профессии ( по сравнению с >строительством)

Конечно, но с этим никто не спорил. Между тем, под "молодостью", как я понял, в контексте настоящего обсуждения понимается не только (и не столько) буквальный возраст (у иных профессий "детство" продолжалось сотни лет), сколько "болезни роста", признаки которых следущие:

- внутреннее (на уровне позиции) cопротивление стандартизации;

- желание любой проект понимать, как уникальный;

- желание видеть свою профессию сверх-уникальной (это по человечески понятно, но мешает проводить полезные аналогии);

- стремление действительно работать "по ремесленечески" - то есть, "по полному циклу" от начала и до конца без разделения функций ;

- нежелание нормировать свою работу и отвечать за сроки;

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

- и др.

Кроме того, Вы пишите:

>2)Все проблемы в программировании из-за отсутствия законов >программирования.

Это очень интересное замечание. Не могли бы Вы раскрыть его подробнее? Что Вы вкладываете в понятие "закон"?

Cпасибо,

Уважаемый Сергей Силантьев!

На этом Форуме принято корректно общаться с коллегами.

пытался найти ссылку на занятную работу
Klaus Renzel Error Handling for Business Information Systems от 16.01.2003
и нашел список литературы


http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm

Appendices/literature.htm

и

http://www.objectarchitects.de/ObjectArchitects/orpatterns/orindex.htm

Уважаемый коллеги!

Обращаем Ваше внимание на материалы, созвучные тематике данного обсуждения:

• http://www.ixbt.com/editorial/fishday/fishday-5.shtml
• http://www.ixbt.com/editorial/programart.shtml

С ошибками можно бороться подробным отчетом.
В NormCAD - отчет включает все формулы, по которым производились вычисления.
http://www.normcad.da.ru