June 8th, 2016

vit_r

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

Арцибашев / Artzybasheff cybernetics 20 years ago I was delighted with Quality Management Systems.

In following 10 years I had gradually understood that "mainstream" QMS cannot be applied for intellectual work.

Toyota - the highest icon in QM world - had produced software that breaks basic safety rules and probably is responsible for killing people. This company also respects 8 hours in an assembly line but wears out engineers with overwork. Motorola had achieved highest levels of quality processes but could not keep with innovations. All quality certificates did not disturb Volkswagen by deceiving the emissions testing...

The roots of this problems are not some evil people who did the good QM in a wrong way but the main principles that QM practitioners accept as granted.

When someone tries to sell you The Quality do not forget this five simple statements:
  1. Certificates are used not to achieve highest quality but to remove responsibility. The main game of all managers is CYA and certificates are very useful for it. (This applies for both customers and contractors.)
  2. People who write standards and criteria for audits usually do not have experience in doing real work. They write rules for an imaginary world.
  3. Many "Best Practices' show excellent short time effects but produce disasters in the long run. Of course only the positive information is reported to the public. (Usually the upper management is also not informed.)
  4. There are no quality metrics and no quality criteria for quality management processes. (The Parkinson's law describes the consequences.)
  5. If quality criteria are defined, they are totally wrong. (For instance, to eliminate all errors we need simply to stop production of anything except reports.)
vit_r

Про ёжика в тумане, зазнайство, языки программирования и вериги

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

Это было вместо эпиграфа.

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

Например, берём простейшее утверждение:
Смысл ОО подхода в разбиении сложности. Можно поменять все методы, оставив класс тем же самым.
Первое предложение игнорируется, а на второе идёт возражение, что это не класс, а тип.

Между тем, у меня и мысли не возникало, что может иметься ввиду что-то кроме изменения кода в процессе развития и осознания требований и ограничений. Один из любимых примеров - это то, что в java.lang.Thread обозначено как @Deprecated. В обычном коде такое, естественно, просто удаляется, имена меняются, количество параметров в вызове становится другим... (А потом люди нервно переписывают код с одной версии библиотеки на другую.)

К тому же в качестве контекста я всё-таки подразумеваю этап анализа и моделирования. (Если бы создателе Жабы так не торопились, они бы так не лоханулись с многопоточностью.) Во время кодирования горизонт обзора сложности гораздо уже и смысл ОО подхода можно игнорировать.