В дебрях водопада

[vit_r]

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

В принципе, это то же самое, о чём пишут ailev или cross_join, только простым человеческим языком.

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

Итак.

(1) Для того, чтобы что-то изобрести, не нужно никаких инженеров. Ремесленник вполне справится.

(2) Для того, чтобы что-то открыть, не нужно науки. Тем более, не нужно для того, чтобы что-то объяснить. Наблюдательность поможет выявить закономерности, а религия всегда найдёт правильное толкование.

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

Теоретически.

Проблемы начинаются, когда в игру вступают слова "новое", "надёжно", "гарантировано"...

(4) Наука не объясняет, она предсказывает. От "Если один укол в треугольнике 90 градусов, а другой - 60, то третий будет 30. Опа! А кто сказал, что мы в Евклидовом пространстве?" до "Мы создали две теории, предсказывающих массу бозона Хигга, но измерения показали, что придётся выдумывать третью".

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

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

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

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

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

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

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

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

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

Вот, собственно, и всё на сегодня по поводу банальных истин.

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

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

Во-вторых, это ничего не доказывает. Потому что тот космический корабль уже долетел до той точки пространства, где с ним случилось "Ха! Могли бы догадаться".

В-третьих, это на самом деле the final frontier. Уникальные задачи, баснословная цена, дикие требования надёжности и сложные, не моделируемые условия. Где ещё приходится учитывать транзит Юпитера? Причём, не как у софтописателей: астрологически, а в гравитационной модели.

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

Comments

[juan_gandhi]

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

А вот насчет софтвера - хочется послать всех этих "инженерных решателей" нахуй. Потому что они ничего не понимают.

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

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

Насчет "трехчастной архитектуры софтвера" надо отдельно пройтись будет, наверно.

[knowyouare]

>>Для меня все эти люди или жулики, или идиоты.

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

[vit_r]

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

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

[vit_r]

Если речь идет о строительной архитектуре, то я за архитектора.

Ох-ох-онюшки. Мы опять про сферических коней в вакууме? :-(

Есть архитектор. Есть инженер-строитель. Есть инженер-прочнист. Это разные роли. И у них разные задачи.

Сравнивая Левенчука и классиком надо всё-таки помнить, что американцы в среднем гораздо лучше пишут. И Левенчук говорит совсем не о софте. Он очень много читает. Но без фильтрации, без проверки, и сомневаюсь, что он разбирается в том, что пересказывает.

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

Да, сравнивать искусство с программированием - это от большого снобизма, но вот пара блогов по теории живописи.
http://muddycolors.blogspot.ch/
http://gurneyjourney.blogspot.ch/

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

Вот про то, как кисточку держать
http://muddycolors.blogspot.ch/2016/04/10-thingsbrushwork.html
http://gurneyjourney.blogspot.ch/2016/05/harold-speed-talks-brushes.html

Короче, всё это из серии "Рабинович напел".

[sab123]

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

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

[vit_r]

Почти такая же разница между программистом и инженером-программистом.

С ошибками в строительстве не легче. Просто там другой подход. Надо будет это поточнее сформулировать.

[sab123]

Там подход очень простой, называется "запас прочности". Рассчитай, потом умножь толщину на три.

[vit_r]

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

[sab123]

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