Таким образом, ООП воспринимается как процедурный механизм для перехода от проблемы к программе без вмешательства понимания. Если бы было возможно учесть абсолютно каждый аспект проблемной области и не нужно было заботиться об эффективности, то этот подход мог бы сработать. Но в действительности при проектировании объектов и их классификации всегда необходим хороший вкус, поскольку необходимо разрабатывать программные объекты, хорошо соответствующие объектам реального мира, но которые можно соединить вместе, чтобы получить жизнеспособную компьютерную систему. Это требует понимания и является строго работой картостроителя. Это проясняет, почему есть ОО проекты, которые заходят в тупик с результатом в виде смеси реальных и вспомогательных объектов, использующих множество избыточных схем адресации для взаимодействия через Брокеры Объектных Запросов (ORB), без ясной концептуальной целостности в инициации, выравнивании нагрузки и журналировании.

Программисты-паковщики часто настолько слабо контролируют свои объекты, что вообще теряют их, и все заканчивается утечками памяти, что приводит к падению программы. Решение паковщика в этом случае — покупка средств обнаружения утечек памяти, а не восстановление контроля над своими объектами, чтобы все работало как надо.

Картостроение и Тотальное Управление Качеством (TQM)

После 2-й мировой войны американцы послали в Японию д-ра Деминга (W. Edwards Deming) помочь привести в порядок промышленность, которая была странной смесью средневековья и индустриальной эры и была разрушена войной. Деминг предложил идеи, включающие сбор статистики о деятельности при массовом производстве, просил занятых этой деятельностью рабочих подумать о способах ее совершенствования и требовал убедиться, что каждый работник понимает, что он делает. Эти идеи позднее развились в то, что мы сейчас называем «Тотальное Управление Качеством» (Total Quality Management — TQM).