Здравствуйте, Ikemefula, Вы писали:

4>> т.е. низкое качество, это когда продукт делает, то что нужно, доставляет минимум проблем потребителю и целом хорошо эксплуатируется?

I>Низкое качество, это когда требования к качеству мутные, непроверяемые — ровно как в твоей формулировке.
I>Хорошесть никак не валидируется, это чистая субъективщина.
I>Один разраб считает, что надо вот так, другой — что надо вот эдак.

Что считает конкретный программист особого значения не имеет, т.к. в конечном счете качество ПРОДУКТА определяется на уровне его потребителей. Например если продукт тормозит, глючит, и падает (плохие эксплуатационные характеристики) то очевидно, что качество низкое. Если всех этих проблем нет — высокое.

4>>Пожалуйста меньше пафоса. Много раз видел изящные архитектуры, божественный код, вылизанные до блеска тесты, хорошая документация, и прочие артефакты сопровождающие цикл разработки. При этом в эксплуатации оказывалась дрянь.

I>Все что ты перечислил к качеству никак не относится, нисколечко.

Допустим у меня есть сервис, разработанный в срок (даже чуть раньше), который обрабатывает несколько 100K транзакций в сутки, в процессе обработки ничего нигде не теряет, аппаратных ресурсов потребляет мало и хлопот в его обслуживании/сопровождении никому не доставляет — качество высокое. Не стоит на ровном месте "квантовую механику" устраиваить.

Другой пример, помню лет может 20 назад было модным в интернетах полоскать Джона Кармака, типа мегатекстура плохая идея, и то не так, и это не эдак, да и вообще пишет на C, хотя давно пора на C++ ...
По факту его наиболее популярные продукты (wolf, doom 1-2, quake 1-3), легко портировались на множество аппаратных платформ (как раз благодаря "чистому" C и архитектуре без лишних премудростей), ресурсов потреблял не много, багов особо нет. По мне качество высокое, даже не "залезая под капот", чисто как для потребителя.

Полагаю тема окончательно исчерпала себя, еще несколько сообщения назад.