Обсуждение

Нет софтверного шовинизма. Есть плохие программисты.

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

Что делать? Учить профессионализму. Собственно, то, чему надо учить, довольно просто. Я формулирую это как последовательность приоритетов(от большего меньшему): конечный пользователь продукта > техническая поддержка > сам программист. Все знают слово usability, но почему-то многие переворачивают эту трехчастную пирамиду кверху основанием. Упорствующих в этом заблуждении я не могу назвать хорошими программистами.

Тут проблема в том, что требуется задуматься о жизненном цикле самого пользователя, а не о usability. Это совсем другие размышления. Кроме того, пользователь тут оказывается не пользователем программы, а пользователем киберфизического устройства, программа в котором спрятана где-то внутри и опосредована железом (например, водитель автомобиля, в котором стоит навороченная куча компьютеров, ни к одному из которых нет интерфейса, но которые тормозят, разгоняют, паркуют и т.д.). К тому же речь идет не только о пользователе, но и о других заинтересованных лицах, которых тоже нужно готовить (ремонтниках, продавцах, производственниках, коллегах-программистах и т.д.). Так что "приоритетом" не обойдешься, нужно подробно объяснять, в каких терминах это все обсуждать, и как именно реализовывать на практике. В принципе, это все сейчас обсуждается как human-system integration (и меньше всего как usability).

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

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

Мы, наверное, по разному понимаем, что такое хороший программист.

Если программист будет следовать Вашим советам, то у него не останется времени на исполнение профессиональных обязанностей :). В реальности разработка софта организована по другому, и это не просто так. Дело в том, что реально есть не только пользователь продукта, но и заказчик. А также менеджмент, другие программерские группы, тестировщики и т.д. Как учит нас системная инженерия, стейкхолдеров, на самом деле, много. Кстати, продвинутые товарищи в стейкхолдеры даже программеров включают. Дык вот, такое большое кол-во заинтересованных лиц постоянно выдвигает какие-то свои требования и претензии. Если на них все реагировать, то получится чистая шизофрения. Поэтому, важное требования состоит в том, что нужно обеспечить концептуальную целостность системы. Лучше плохонькая целостность, чем ее отсутствие. На практике, это означает, что 99% требований стейкхолдеров идут лесом, как не вписывающиеся в концепцию системы, или реализуемые другими способами. Политкорректно для них выделяют самый низкий приоритет, а если не политкорректно, то могут и прямо послать. Можно, конечно, говорить что это программеры плохие, но у них на самом деле стоит задача реализовать оставшиеся 1% более-менее разумных требований. Как определяется разумность - это уже другой вопрос. Тот кто знает сию процедуру, тот и обладает реальной возможностью проталкивать решения.

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

Не человек для субботы, а суббота для человека. Если наоборот то желаю успешных продаж при таком подходе. А покупателям можно объяснять, что их требования не вписываются в концепцию системы.

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

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

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

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

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

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

Есть предположение, что часть того, о чем софтверщики уже понимают о требованиях и системах, дойдет до системщиков с описанным лагом в 10 лет ;-) Анатолий как Вы думаете, в чем причина существования такого лага &

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

Спасибо за обстоятельный ответ ! Думаю что помимо содержания работы абстрактность, рефлексия и т.д., принципиальное значение имеет длительность и вариативность ЖЦ. При коротком внутреннем цикле ЖЦ ( если подскажите лучший термин буду искренне рад) эволюция методов и практик идет значительно быстрее. Например одна из ключевых "фишек" гибких подходов состоит в так называемом Learning by doing, т.е. процесс приспосабливается итеративно в ходе самого проекта и попутно происходит обучение процессу участников. SEI в свое время насчитал больше ста видов ЖЦ, не все виды ЖЦ применимы к одним и тем же проектам однако часть видов ЖЦ можно эмпирически сравнивать между собой, и использовать ходы найденные в Разработке ПО применительно к системам со схожими жизненными циклами.