Утилитарность против академичности

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

В каком смысле ?

> По статистике более 90% проектов разработки программного обеспечения -- провальные. Неужели это все операционные системы?

Тупое руководство.

+ отсутствие технологического подхода. Упование на собственную гениальность и неповторимость.

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

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

> А что бы ты сказал о производстве, например автомобилей, где манагер может объявить "так, ребята, будем вытачивать движки из дерева, ибо это быстрее/дешевле/есть возможность купить древесину со скидкой/у нас нету специалистов по металлу а по дереву - ну просто завались/рама, изготовленная в соседнем отделе, не выдержит вес движка из металла/ещё что-нибудь подобное"? И потом какое-нибудь моторостроительное ПТУ объявит, что перестаёт обучать работе с металлом, а обучает работе по дереву взамен, из сугубо практических соображений? Бред? А в софтиндустрии именно так и происходит.

Я не понимаю такие аналогии. Приведи конкретный пример ?

> Я не понимаю такие аналогии. Приведи конкретный пример ?

Хм, если бы ты попросил привести пример где это не происходит, я бы затруднился...

Блог, наполненный грусными историями про m$ sql "server" http://rentacoder.com/CS/blogs/default.aspx

на что обречён пипл, связавшийся с недоделаными типо питона:

http://evanjones.ca/python-memory.html

http://sin-avatar.narod.ru/stories/sad_story_about_python/index.html

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

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

и ещё тыщя и одно подобное.

>на что обречён пипл, связавшийся с недоделаными типо питона:

Зря ты дал эти ссылки. :)

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

Дык вроде обсуждение MIT давно скончалось... А питон, ну почему бы не пообсуждать? Он и в топике как раз упоминается. Для меня вообще приступы серпентофилии, овладевающие многими, остаются загадкой.

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

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

> http://evanjones.ca/python-memory.html

[Note: This problem is fixed in Python 2.5] Да, в более ранних версиях был тупой GC с подсчетом ссылок. Был и workaround --- weakref. Язык развивается. Или ты хочешь сказать, что твой любимый Лисп прям такой белый и пушистый появился сразу в 1959 году?

> http://sin-avatar.narod.ru/stories/sad_story_about_python/index.html

Мальчик просто не понимает, как устроено управление памятью. Я проверил --- кое-что питон освобождает таки. У остатков же, ноги растут примерно оттуда же, что и у утечек памяти в FF --- glibc'шные malloc/free используют sbrk, который умеет изменять размер кучи только с конца. И мальчику дали правильный совет --- изменить стиль программирования и не выделять диких объемов, но мальчик не способен понять, что существуют и другие подходы, кроме if/for/def/class.

Про MSSQL ничего сказать не могу, я с ним не много работал, но уверен, что большинство проблем от того, что недоумки верять рекламным заявлениям MS и, в результате, применяют его там, где этого делать не стоит (может, и вообще нигде не стоит, лучше PostgreSQL взять :) ).

> применяют его там, где этого делать не стоит (может, и вообще нигде не стоит

дык о том и речь была, что из-за безграмотности применяют не то или не так, ссылаясь при этом на разнообразные "у кого-то вроде по слухам работает", рекламу или свои эмоции, а не на фундаментальные знания, полученные в ВУЗе.

> Все хуже, Zulu! Приходит человек, в резюме МГУ, всякие слова красивые, лисп и пролог, а на деле 2х слов связать не может внятно. И такие-косяками.

Потому что в МГУ тоже дебилы! Дебилизация, дорогой Шаман, не обошла и это славное заведение.

У меня у самого сейчас группа 3 курса. Они самые, МГУшники. "Из песни слова не выкинешь", и дебила не сделает умным даже МГУ.

> но на конвейер как-то не очень похоже.

:) ну извини. Конвеер в производстве нужен для массового клонирования ранее придуманного прототипа. В программировании клонирование выполняется замечательными командами make и cp. make и cp - это конвеер в твоем понимании. Я могу налипить столько одинковых прототипов сколько понадобится :) Здесь следует рассматривать понятие технологичности на уровне инжерерной разработки. А программирование тут ни чем не отличается от любой другой технической отрасли.

> В программировании клонирование выполняется замечательными командами make и cp. make и cp - это конвеер в твоем понимании. Я могу налипить столько одинковых прототипов сколько понадобится :)

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

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

Вот такая хня на практике получается. Типа "серебрянной пули не существует" (С) все тот же Брукс. Даже если эту пулю лепят из "высокотехнологичного конвейера".

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

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

> Странно, вроде бы это фундаментальное свойство не мешает создавать космические корабли и подводные лодки, а писать программы оно мешает?

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

> Просто нужно устанавливать реальные сроки и всегда закладываться на "всякий случай".

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

> О! Какое откровение! Ну конечно это применимо только к разработке ПО

Конечно же.

> Какой из перечисленных сотрудников у вас отсутствует ?

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

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

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

> В каком смысле ?

В прямом.

> Тупое руководство.

Ну да, ну да. Мсье знает секрет "серебрянной пули" и готов поделиться им с тупым миром. Остается только задать вопрос, почему при таком фантастическом уме и обладании столь потрясающим артефактом мсье все еще не руководит компанией, которая считается бесспорным лидером ИТ-отрасли?

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

Да пожалуйста. Секрет очень прост, он описан у того же брукса. Кадры решают все. Нужен опытный менеджер, опытный аналитик, грамотный программист и т.д. и подобрать их надо так чтобы они все сработались. Команда дилетантов ни на что не способна. Если читать того же брукса, то эта мысль проходит красной нитью через всю книгу. Бестолковый менеджер устанавливает неправильные сроки на проект, ни разу "небитый жизнью" программист обладает безудержным оптимизмом и т.д.

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

Тю. А вы думаете в любой другой технической области дела обстоят по другому ? Вы думаете, что найдется человек который досконально от начала и до конца знает как спроектирована подводная лодка или космический корабль ? Правильный ответ "нет". Таких людей не существует. Каждый человек отвечает за свой участок работы, так было, так есть и так будет всегда и везде, в любом производстве. "Фундаментальная" проблема программирования из-за которой большинство проектов провальны - отсутсвие развитого станадртизованного языка общения между профессионалами различных специальностей. Аналитик не понимает как что-то объяснить программитсу, программист не понимает как нечто объяснить другому программисту, тестеру, внедренцу и т.д. Следовательно по факту разделение труда отсутвует. Все лобают какую-то свою работку, а для чего она нужна никто не понимает. Задача менеждера проекта состоит прежде всего в том, чтобы организовать правильную среду общения между различными разработчиками. Только тогда проект будет управляем, с гарантированным, качественным результатом.

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

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

> Каждый человек отвечает за свой участок работы, так было, так есть и так будет всегда и везде, в любом производстве.

Однако на заводе я могу подойти к любому токарю с штангенциркулем и проверить, точно ли по чертежу изготавливается шестерёнка. А также причинить сплаву, из которого она зделана, соответствующие тесты, и удостовериться, что он соответствует требованиям на прочность. Также я смогу обратиться к тому, кто сотворил чертёж и назначил, какой сплав применится, и спросить "почему так?". Он мне справедливо ответит "иды на йух, я ботал сопромат в институте и я знаю чё делаю". Я пойду, нет, не на йух, а в институт де преподаютсопромат, и спрошу "почему так?" и мне справедиво ответят "кури теормех", а теормех - наука, а не мнение одной известной фирмы, там всё точно. Современное же програмиирование - это шоманство (господ народных целителей прошу не обижаться, я не это имел в виду). Как ты докажеш что твоя прога работает? "Мамой клянус!". http://www.artima.com/weblogs/viewpost.jsp?thread=71730

> Your code sucks if it doesn't work.

> Does your code work? How do you know? Can you prove it?

Как ево хотябы не доказать на правильность, а просто проверить прочтением?

> Your code sucks if it's hard to read.

> Your code sucks if it's not understandable.

Допустим, извесный программёр за неделю произвёл 1000 строк кода. Кто их станет читать, и тем более разбираться в них всех, чтобы установить, что тама нету баги? Это ведь не минутное дело, как с шестерёнкой...

И почему, пёс побери, у меня на заводе каждый токарь решает, из чего и каким размером делать шестерёнку???

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

В нормальном конвейере это _не_нужно_, и более того, это основной признак конвейера. Инженер не станет разъяснять токарю основы сопромата, сталевары - медоды варки стали инженеру, а токарь - премудрости своего дела тестерам и тем более юзверям.

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

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

> Кустарность не выгодна.

Не выгодна

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

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

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

Как они отличат? И кстати, где оне? Покажи хоть одного такого.

> Современное же програмиирование - это шоманство (господ народных целителей прошу не обижаться, я не это имел в виду). Как ты докажеш что твоя прога работает? "Мамой клянус!". http://www.artima.com/weblogs/viewpost.jsp?thread=71730

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

_Контроль_ качества_ труда программиста это тестирование (в основном). У того же брукса написано, что тестирование ПО занимать чуть ли не больше времени чем его разработка. И это правильно.

> В нормальном конвейере это _не_нужно_, и более того, это основной признак конвейера. Инженер не станет разъяснять токарю основы сопромата, сталевары - медоды варки стали инженеру, а токарь - премудрости своего дела тестерам и тем более юзверям.

Про констукторскую и технологическую документацию слышал ? Чертежи там всякие ? :) Как раз придумана для того чтобы каждый занимался своим делом и понимал другого, с которым взаимодействует.

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

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

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

Да очень просто. Про такое понятия как "портфолио", "репутация" и т.д. слышал ? Легко проверяется. Как ты узнаешь, что новая модель БМВ также хороша как и предыдущая ?

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

Любая организация. Они гарантируют, что по их расчетам стиральная машинка прошевелится как минимум 3 года. Если нет, то они тебе ее починят/заменят за свой счет. Теперь покажи мне аналоги в ИТ, желательно с ценами (я знаю, что такие есть, но стоит это совершенно других денег) :)

> Чтобы бороться с браком должен быть налажен _контроль_качества_.

Контроль качества --- это лишь малая часть. Если у тебя производство настолько говёное, что требованиям качества удовлетворяет всего 1 экз. из 1000, то выходов два: 1. вылететь в трубу 2. снижать планку качества до тех пор, пока пипл хавает. Как ты думаешь, что выберет среднестатистический манагер?

> _Контроль_ качества_ труда программиста это тестирование (в основном).

Тесты покрывают лишь малую часть. Проверено в крупной американской быдлоконторе, сертифицированной по ISO9000, с офигительным тех. процессом и индо-китайскими программистами. Пока обезъянам дают в руки оружие массового поражения aka C/C++, никакие тесты, архитектуры и дизайны не спасут.

> Про констукторскую и технологическую документацию слышал ? Чертежи там всякие ? :) Как раз придумана для того чтобы каждый занимался своим делом и понимал другого, с которым взаимодействует.

Объемы несоизмеримы. На какой-нибудь автомобиль имеется грузовик этой документации, произведенный батальоном конструкторов. И еще такой же грузовик на само производство. А при разработке ПО численность "конструкторов" aka архитекторов и дизайнеров несоизмеримо меньше, хотя сложность выше, да и тот же Мерседес клепает свои автомобили уже более ста лет --- всё что можно, отлажено и проверено временем. У программных продуктов срок жизни много меньше, т.к. возможность повторного использования стремится к 0, как у частей автомобиля, вырезанного из цельного куска стали (частей нет --- монолит-с). А документации на само производство как правило 1-2 странички размытого текста.

Любая организация. Они гарантируют, что по их расчетам стиральная машинка прошевелится как минимум 3 года. Если нет, то они тебе ее починят/заменят за свой счет. Теперь покажи мне аналоги в ИТ, желательно с ценами (я знаю, что такие есть, но стоит это совершенно других денег) :)

:) Стоимость гарантийного обслуживания закладывается в цену товара. Любая адекватная контора осуществляет сопровождение той программной системы, которую она разработала. Разумеется за деньги. За бесплатно даже стиральные машинки не ремонтируют. Люди с жизненной позицией "мы тут вам написали, а вы уж сами *битесь как хотите" долго в бизнесе не протянут.

И потом, кто сказал, что написать программу это дешево ?

> Контроль качества --- это лишь малая часть. Если у тебя производство настолько говёное, что требованиям качества удовлетворяет всего 1 экз. из 1000, то выходов два: 1. вылететь в трубу 2. снижать планку качества до тех пор, пока пипл хавает. Как ты думаешь, что выберет среднестатистический манагер?

Если у тебя производство говеное, то ты полюбому вылетишь в трубу. Это просто вопрос времени.

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

> Тесты покрывают лишь малую часть. Проверено в крупной американской быдлоконторе, сертифицированной по ISO9000, с офигительным тех. процессом и индо-китайскими программистами. Пока обезъянам дают в руки оружие массового поражения aka C/C++, никакие тесты, архитектуры и дизайны не спасут.

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

> Объемы несоизмеримы. На какой-нибудь автомобиль имеется грузовик этой документации, произведенный батальоном конструкторов. И еще такой же грузовик на само производство. А при разработке ПО численность "конструкторов" aka архитекторов и дизайнеров несоизмеримо меньше, хотя сложность выше, да и тот же Мерседес клепает свои автомобили уже более ста лет --- всё что можно, отлажено и проверено временем. ... >А документации на само производство как правило 1-2 странички размытого текста.

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

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

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

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

> Стоимость гарантийного обслуживания закладывается в цену товара.

Не совсем. Если ломается стиральная машинка, то всё понятно --- несем в сервис. А если падает программа, то в 99.9% случаев получим ответы: 1. Не делайте так, через пол-года, возможно, исправим в очередном сервис-паке 2. Перезапустите и не е* нам мозг.

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

> Если у тебя производство говеное, то ты полюбому вылетишь в трубу. Это просто вопрос времени.

Даже если у тебя отличное производство, ты всё равно вылетишь в трубу. Это просто вопрос времени, следуя давно известной мудрости: всё имеет своё начало и свой конец.

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

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

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

О! Т.е. конвейер в ИТ-индустрии --- это такая особенная штука, где за станком должен обязательно стоять сотрудник с высшим образованием, а желательно к.т.н.?

Сотрудники были вполне ПТУ-шного уровня, только вот описанная тобой схема --- нифига не конвейер и ПТУ-шники туда не вписываются.

> Блин, так это и есть проблема менеджмента.

Нифига. На данный момент это проблема технологий.

> В твоем случае процесс разработки построен так, что остутствует этап проектирования.

Он есть. Но... Компания производит софт на заказ. Если проводить аналогии с классическими производствами --- это ОКР, а ни разу не конвейер. Соответственно, объемы ОКР в софтостроении ничуть не меньше, просто размазаны бо бОльшему количеству штук этих ОКР. Иначе не получается --- рынок.

> Нет основного результата проектирования - внятной проектной документациии.

Нет и, на данном этапе развития, быть не может. Об этом ниже.

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

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

> Возможность повторного использования у программ нормальная

Не в существующих подходах к созданию программ. В самом массовом --- ООП --- повторное использование просто отвратительное. Самым перспективным, на данный момент, мне видится Language Oriented Programming (не в гордом одиночестве, разумеется --- no silver bullet), но он, к сожалению, слишком мало распространен и его тяжело испробовать на реальном проекте.

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

> (даже не думал, что услышу такое на _линуксовом_ форуме)

А причем тут линуксовость? Или ты о unix commandline tools? Да ну, брось. Давно ты последний раз видел программу не на скриптовом языке, которая использует commandline tools? Я _очень_ давно.

Итого:

1. количество ОКР в софтостроении много больше, чем в классической индустрии, поэтому на качественное проведение ОКР не хватает ресурсов.

2. массово используемый инструментарий слишком убог, чтобы обеспечить приемлемый коэффициент повторного использования -> п. 1.

3. как следствие п. 1, процент ОКР в софтостроении несоизмеримо выше, чем в классической индустрии, поэтому требуются существенно более квалифицированные и дорогие кадры.

В общем, ИТ движется, конечно, в направлении превращения в более классическую индустрию, но довольно медленно. Думаю, до моей пенсии положение существенно не изменится. :)

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

Ты знаеш термин "наработка на отказ ... часов"? Знаеш как вычисляется её значение? Для хеловорда на странички полторы сумееш _вычислить_ аналочичный параметр?

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

> _Контроль_ качества_ труда программиста это тестирование (в основном). У того же брукса написано, что тестирование ПО занимать чуть ли не больше времени чем его разработка. И это правильно.

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

> или им будет банально неудобно пользоваться.

Телевизер/холодильник/етц, которым неудобно пользоваться, мало кто купит. Потому что довольно очевидно, что им не удобно пользоваться. А чтобы определить, что неудобно пользоваться прогой, нужно 1) довольно долго с ней поработать, когда деньги уже заплочены 2) иметь возможность сравнить с другими, для ознакомления с которыми тоже нужно время, и 3) чтобы избавиться от неудобной проги, нужно как минимум время еа переобучение. Это дорого. Посему, фирма, выпустившая глючный телевизер, терпит убытки, а софтовая, которая выпустила гючную прогу, получает дополнительную прибыль за счёт платной техподдержки. Сама по себе платная техподдержка - маразм, существующий насколько я знаю, только в области ПО.

> Про констукторскую и технологическую документацию слышал ? Чертежи там всякие ? :) Как раз придумана для того чтобы каждый занимался своим делом и понимал другого, с которым взаимодействует.

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

> Нормальный менеджер должен быть специалистом или хотябы разбираться во всех областях, где работают его подчиненные

Может быть. Ты где-нибудь видел нормального менеджера? Который разбирался бы хотя бы настолько, чтобы понимать, что от всяких висуалделфей нужно бечь как от чумы?

> Да очень просто. Про такое понятия как "портфолио", "репутация" и т.д. слышал ? Легко проверяется. Как ты узнаешь, что новая модель БМВ также хороша как и предыдущая ?

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

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

И что это за реал альтернативный ? Что там со структурой и синтаксисом не так ?

Чел же написал, что решает на фортране задачки по алгебре за 10-11 класс. Не мешай ему этим гордиться.