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

А то ’сложность’ которое про оценочное суждение человека, для него есть другие слова. Да вот хотя бы ’оценочная сложность’.

Занимательное чтиво. Но для определения сложности кода есть вполне себе сформулированные и осязаемые метрики — например цикломатическая сложность.
ru.m.wikipedia.org/...​Цикломатическая_сложность
Читабельность, и понятность и т.д. это просто отдельные штуки. И не стоит их путать с сложностью.

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

И ещё одно. Так долго говорить о культуре, и даже не заикнуться, что страна !=культура. И что, приводящиеся лейблы ’украинцы’ , ’британцы’ относятся к представителям культуры, а не страны. По крайней мере контекст статьи на это сильно намекает.

мой комментарий никак не касается «правильно» ли «неаправильно» спроектированной программы. Он касается того, что вкладывается в понятие «exhaustive testing»
Если следовать мейнстримным практикам (use cases), то насколько тестирование exhaustive связано с тем, как считать coverage.
Если даже не углубляться, а следовать например Linear code sequence and jump (LCSAJ)
en.wikipedia.org/...​ar_code_sequence_and_jump
И при этом стремится к полному покрытию, то даже для небольшого проекта это будут огромные цифры.
Перебрать их все, что вручную что автоматически, это ооочень долго. Даже может быть дольше чем весь цикл жизни проекта.
Вот поэтому и "

xhaustive testing возможно. Просто в подавляющем большинстве случаев оно не возможно за вменяемое для проекта (и даже для человека) время.

"

Если точнее, то exhaustive testing возможно. Просто в подавляющем большинстве случаев оно не возможно за вменяемое для проекта (и даже для человека) время.
Это конечно если корректно считать coverage, а не как обычно.
Формулировки наше все)

Муз опыт =! знание DSP
И это только на первый взгляд может показаться, что знание предметной области является ключевым для QA.
Нет, ключевым навыком для QA есть (внезапно!) тестирование софта . Что бы там ни подразумевалось под тестированием.
Знание предметной области может быть бонусом, но не более.
ИМХО, предметная область, в данном случае DSP нужна тому кто принимает бизнесс решения. Но вот там, как раз не мейнстрим иметь еспертизу в предметной области...

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

Не будучи мало мальски експертом в IT, уже далеко не так очевидно что из сказанного ’експертами’ есть валидное утверждение/прогноз, а что полнейший bullshit.
Проблема оценки утверждений/прогнозов/результатов работы в области, в которой оценивающий не является експертом на самом деле намного шире чем кажется.
Нельзя так просто взять и купить чью-то еспертизу. Потому что хочется каких-то гарантий что эта експертиза во-первых есть, а во вторых не полный bullshit
И тут есть 2 выхода — довериться authority (человеку или организации), или разбираться по существу (да, по ходу разбирательств можно и самому стать експертом)
Эта проблема не решена по большей части нигде. Исключение разве что научное сообщество (фундаментальной науки).
А господам политикам постоянно (по крайней мере так оно выглядит) приходиться верить практически на слово очередным ’експертам’.

А с каких пор прочтение книги = понимание прочитанного = развитие?
И с чего вы решили что прочитанное = релевантный опыт ? Если что, только релевантный опыт, а не весь подряд, остаётся надолго. Соответственно, только релевантный опыт может быть приравнен к развитию.

Hint — ассинхронная коммуникация наше все. Внезапно (на самом деле не очень) если не торчать на митингах, а писать по существу, обдуманно в чем собственно дело, то можно аффективнй поработать, затратив при этом меньше времени ! Профит!

Для общения есть чатики. Отдельные чатики специально чтобы трындеть. А если совсем уже хочется живьём, то выбираться специально на пообщаться.

Например 3% вместо 5%

А каким боком такие условия это благоприяитный климат? Особенно от утечки мозгов

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