Почему-то автор статьи и многие комментаторы искренне, как мне показалось, считают, что данная «проблема» касается только программирования и программного обеспечения.
Вот, например, автор боится идти по мосту, потому что программисты, которые писали программы проектирования мостов, не знали до конца, что именно они делают, а заказчик программы (по сути — конечный её пользователь) вообще не разбирается в программировании.
Но при этом автор забывает, что мост проектировала не только программа, но и люди. И не поверите — 99% проектировщиков мостов и других сооружений и зданий не являются специалистами в теории упругости. Да многие (очень многие) не вспоминают даже простого сопромата при проектировании строительных конструкций. А еще очень мало кто из них является специалистом в материаловедении и не представляет себе ни состава используемой стали, ни процесса прокатки двутавровых балок. Конечно, проектировщик, который знает всю подноготную строительства от добычи ископаемых до покраски фасадов ценится выше. Но таких, честно скажу, не много.
Да, у нас, у проектировщиков, все то же самое — разделение труда и совершенно слепое использование чужих наработок. Один институт разрабатывает состав бетона, второй разрабатывает технологию его укладки, третий — сталь для арматуры, четвертый — профиль арматуры, пятый — формирует серию на изготовление железобетонных плит, шестой — просто применяет их в проекте. Всё то же, что и в программировании — есть низкоуровневая разработка, есть высокоуровневая, есть библиотеки готовых функций инженерных решений, есть конечные программы проекты, использующие их.
А заказчики у нас техзадание вообще писать не умеют. Совершенно. Абсолютно. Приходят и просят проектную организацию саму себе задание написать и ставят под ним подпись.
И это в любых областях нашей жизни так — терапевт в районной поликлинике — не микробиолог и может не представлять себе, как именно лекарство будет воздействовать на ваши клетки. А вы, как заказчик работы терапевта — тем более.
Так что еще можно поспорить, кто быстрее погубит мир))
Вот, например, автор боится идти по мосту, потому что программисты, которые писали программы проектирования мостов, не знали до конца, что именно они делают, а заказчик программы (по сути — конечный её пользователь) вообще не разбирается в программировании.
Но при этом автор забывает, что мост проектировала не только программа, но и люди. И не поверите — 99% проектировщиков мостов и других сооружений и зданий не являются специалистами в теории упругости. Да многие (очень многие) не вспоминают даже простого сопромата при проектировании строительных конструкций. А еще очень мало кто из них является специалистом в материаловедении и не представляет себе ни состава используемой стали, ни процесса прокатки двутавровых балок. Конечно, проектировщик, который знает всю подноготную строительства от добычи ископаемых до покраски фасадов ценится выше. Но таких, честно скажу, не много.
Да, у нас, у проектировщиков, все то же самое — разделение труда и совершенно слепое использование чужих наработок. Один институт разрабатывает состав бетона, второй разрабатывает технологию его укладки, третий — сталь для арматуры, четвертый — профиль арматуры, пятый — формирует серию на изготовление железобетонных плит, шестой — просто применяет их в проекте. Всё то же, что и в программировании — есть низкоуровневая разработка, есть высокоуровневая, есть библиотеки готовых
функцийинженерных решений, есть конечныепрограммыпроекты, использующие их.А заказчики у нас техзадание вообще писать не умеют. Совершенно. Абсолютно. Приходят и просят проектную организацию саму себе задание написать и ставят под ним подпись.
И это в любых областях нашей жизни так — терапевт в районной поликлинике — не микробиолог и может не представлять себе, как именно лекарство будет воздействовать на ваши клетки. А вы, как заказчик работы терапевта — тем более.
Так что еще можно поспорить, кто быстрее погубит мир))