Заметки о качестве ПО (Hobday)

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

Определение и сигналы автора

Рабочее определение Hobday: "качество - это отсутствие проблем". Его критерий проверки эмпиричен: если тщательное тестирование и 100 экспертов не находят проблем, вещь, вероятно, идеальна. Идеал недостижим, поэтому качество - это спектр, к которому приближаешься с убывающей отдачей: переход от "80%" к "90%" обходится значительно дороже, чем путь до первых "80%".

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

В этом списке заметно не хватает двух вещей, и на HN обратили внимание на обе. Безопасность не упоминается вовсе - один из комментаторов (arscan) оправдывает этот пропуск тем, что безопасность напрямую конкурирует с удобством использования и интероперабельностью, и эту ценность разделяют не все, поэтому она относится к другой оси, нежели эти шесть. Поддерживаемость тоже отсутствует, хотя некоторые комментаторы называют именно её настоящим признаком качества: поддерживаемый код позволяет остальным сигналам не деградировать со временем.

Качество организационно и умирает с масштабом

Опорный тезис: качество - свойство организации, а не кода. Оно складывается из возможностей (есть ли люди, способные его делать) и аппетита (позволяет ли им организация). По опыту Hobday, примерно в 100% случаев, когда организация выпускает качественное ПО, причина в том, что этого хотело руководство. Он также перечисляет 38 своих убеждений, которые предпочёл бы видеть ошибочными, - по большей части это вариации на темы: "чем больше людей прикасается к ПО, тем сложнее удерживать качество", "качество требует разрешения сверху" и "дизайн-системы и другие процессы, призванные помогать, могут также вредить".

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

Дальше большую часть страницы занимает стена цитат в защиту тезиса о том, что работать должны только маленькие команды: Patrick Collison ("крупные компании не умеют превращать капитал в хороший софт"), Dan Luu (культура совершенства выживает в небольших компаниях, но погибает после гиперроста; компаниям выгодно "находить обходные пути вместо создания работающего продукта"), Steve Jobs о монополиях, где продажи и маркетинг вытесняют продуктовых специалистов, Gergely Orosz о стимулах, никогда не вознаграждающих исправление малозаметных проблем, линия эншиттификации Cory Doctorow и ещё примерно два десятка дизайнеров, сходящихся на том, что "между числом сотрудников и качеством для конечного пользователя существует обратная корреляция". Adam Michela определяет оптимальный размер примерно в 30 человек (5-10 инженеров, 2 дизайнера). В плане аргументации это самое слабое место заметок - здесь используются свидетельства вместо доказательств, одна и та же мысль повторяется на двадцать ладов, а p1necone на HN выдвигает очевидное возражение: крупные организации могут добиваться качества силами небольших автономных команд под конкретные продукты, а убивают его как раз "разумные" шаги по консолидации (общие библиотеки компонентов, общие реализации).

Что стоит сохранить

Два раздела заметно конкретнее основного тезиса. Hobday составляет каталог реальных программ контроля качества в компаниях, подкрепивших намерения структурой, а не просто заявивших о заботе: политика Linear "баги важнее всего" и "Quality Wednesdays", проходящая дважды в год "Quality Week" в Zed (остановка разработки возможностей, сокращение ситуаций, когда редактор паникует), команда "UX Paper Cuts" в GitLab, позиция "Head of Craft" в Stripe, Chief Quality Officer в Automattic, "Quality Ombudsperson" в Sonos, а также инициативы Meta, Microsoft, HubSpot и Shopify. Общий паттерн - горизонтальная команда с правом чинить мелкие недочёты и с явным отсутствием квот на новые возможности.

Второй раздел - список из 20 интерфейсных деталей, повышающих удобство: то микромастерство, которое незаметно, когда оно есть, и раздражает, когда его нет. Среди них: широкие траектории движения мыши во вложенных меню, "coyote time" для сочетаний клавиш (комбинация не отменяется в ту же секунду, если раньше времени отпустить не ту клавишу), сохранение введённых данных при уходе с экрана, постоянство объектов для элементов, общих для разных представлений, открытие контекстных меню так, чтобы действия попадали в одно и то же место относительно курсора, и задержка первого тултипа при мгновенном показе соседних, когда один уже открыт.

Где определение даёт сбой

Обсуждение на HN удачно корректирует исходный тезис. "Отсутствие проблем" - это ошибка овеществления (satisfice): проблема является проблемой только потому, что кто-то счёл её таковой, а это возвращает к вопросу о том, чьё мнение важно и что эти люди чувствуют, - ближе к формулировке Gerald Weinberg "качество - это ценность для какого-то человека". Другие апеллируют к "устойчивости перед трудностями" и антихрупкости (высококачественная кодовая база - та, которую дёшево менять при усложнении условий) или указывают, что всё это было строго описано задолго до изобретения собственных шести сигналов: в работах Walter Shewhart 1931 года, в производственной системе Toyota, в модели ценности для стейкхолдеров ISO 25010 и в эмпирических исследованиях DORA.

Связь с другими страницами

Аргумент о масштабе перекликается с темой, проходящей через критику агентного кодинга в вики. peril-of-laziness-lost приводит структурно идентичный довод относительно другого участника: качество (в том случае - простота) размывается, когда у генератора кода нет ограничений, заставляющих его заботиться о результате, - у Cantrill это LLM без свойственной человеку лени, а у Hobday это крупные организации без аппетита к качеству. clean-code-coding-agents утверждает, что с агентами структура кода важна ещё сильнее, так как неряшливый код впустую расходует ограниченный контекст, - это позиция "поддерживаемость как качество", закрывающая пробел, замеченный HN в шести сигналах Hobday. А no-silver-bullet-llms повторяет скептический шаг, настаивая, что качество упирается в структурные ограничения (у Brooks это сущностная сложность, здесь - комбинаторика связей), а не решается усилиями или инструментами.