Причины большей популярности внутренне посредственных систем

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

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

1. Ошибки восприятия. Эти причины отвечают не на тот вопрос, но важно отделить ошибки восприятия от ошибок дизайна.
   1. Преувеличение. По-настоящему инженерно неудачные системы на самом деле погибают под собственной тяжестью и непопулярны. И, наоборот, удачность других систем может быть преувеличена. По крайней мере, всё может быть не так однозначно, и страдая в одном, система может иметь преимущество в другом, что несправедливо упускается из виду.
   2. Внимание. Популярные системы получают более пристальное внимание, особенно, с практической точки зрения, поэтому их недостатки очевидней недостатков непопулярных систем.
      Существуют примеры появления фан-базы, которой нравится воображаемо использовать малоизвестную систему, приписывая ей несуществующие или преувеличивая существующие достоинства, при этом не замечая никаких недостатков, потому что воображаемое или малоактивное использование позволяет легко игнорировать эту составляющую. Некоторые из этих поклонников на самом деле ненавидели бы свой предмет обожания, столкнись бы они с ним вплотную, другим бы пришлось активно заниматься самообманом.
2. Если система оказывается не такой уж неудачной, почему недостатки со временем не исправляются?
   1. Недостаток может быть следствием тех свойств, которые обеспечивают преимущества, и устранение одного приведёт к уничтожению и второго.
   2. Недостаток может являться малоприоритетным или трудноустранимым, но терпимым в ряде условий, которые тем не менее обеспечивают популярность.
3. Компромиссы. Популярность нередко требует выполнения более широкого спектра условий, что часто решается внедрением компромиссных решений, которые в восприятии системы делают её менее удачной для каждого конкретного применения. Бескомпромиссность в выборе лучших решений может приводить к избыточному дроблению аудиторий, препятствующего накоплению критической массы и дальнейшему росту популярности за её счёт.
4. Время. Создание более удачных систем может требовать большего времени на принятие решений, из-за чего момент может быть упущен, или даже приводить к аналитическому параличу. Тогда система может так и оставаться воображаемо прекрасной в некоторых отношениях, которые тем не менее неважны при отсутствии своевременного полного решения. Время — это ещё одно место для компромисса, потому что есть что-то похуже недостаточно хорошего решения — это отсутствие решения, когда оно нужно.
5. Подсистема. Популярность системы может быть обусловлена лишь популярностью основной надсистемы, частью которой она и является, поэтому напрямую не обусловлена исключительно её качествами. В то же время вероятность создания более хорошей подсистемы ниже, чем более плохой, как из-за недостатка времени, так и из-за того, что и количество людей, способных сделать лучший вариант меньше тех, что могут сделать похуже. Соответственно, недостаточно хорошие подсистемы чаще становятся частью хороших систем.
6. Приоритет. Почему в целом удачная система, вообще, может содержать в себе в чём-то недостаточно удачные подсистемы?
   Времени почти всегда недостаточно, поэтому правильная приоритезация является необходимой составляющей создания успешной системы. Без жертв здесь не обойтись, поэтому в неидеальности отдельных частей нет ничего удивительного. Наоборот, уделение преувеличенного внимания к улучшению менее приоритетных свойств подсистем способно привести к ухудшению системы в целом.
   Со временем условия могут измениться, на первый план могут выйти совсем другие подсистемы, но свойства уже останутся.
7. Наследие. Для популярности может быть критичным возможность задействования полезного наследия в широком смысле, что, однако, может приводить к дополнительному накоплению и проблем от предыдущих систем, если не были задействованы меры противодействия, которые, впрочем, тоже не бесплатны, а потому и не лишены недостатков. Требования сохранения работоспособности наследия могут существенно сужать возможности по внесению изменений, улучшающих систему исключительно с точки зрения текущего кода.
8. Человеческие недостатки. Несомненно, эта часть человеческой сущности тоже имеет серьёзное влияние на свойства проекта
   1. Многим разработчикам довольно трудно не наградить свои детища хоть небольшим количеством сомнительных свойств без каких-либо обоснований, кроме того, что проект делают несовершенные существа.
   2. Между разработчиком и пользователем есть существенная ассиметричность в понимании системы, что может приводить к неадекватным требованиям со стороны ряда пользователей, которым разработчики часто не в силах противостоять. Система либо включает в себя мусорные требования, либо рискует потерять в популярности.
   3. Создатели более удачных систем могут гробить их потенциальную популярность, неоправданно цепляясь за второстепенные улучшения, из городости не желая отступать даже в мелочах, изначально выбранных произвольно.

Можно ли что-то предложить для улучшения ситуации? Попробую, не претендуя на полноту, в частности, не затрагивая многие аспекты маркетинга.

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

Для содействия популярности более удачных систем:

1. Идти на компромиссы, когда это необходимо. Идти на уступки во второстепенных качествах, если их отсутствие несёт угрозу раскола, особенно в относительно произвольно выбираемых частях.
2. Закладывать эволюционность
   1. И отказываться от чрезмерного планирования как попытки предвидеть всё. Предпочитать разведку боем и внесение изменений.
   2. Ради возможности сосредоточения на главном, позволять быть слабым местам во второстепенных частях, в которые, тем не менее, желательна закладка возможности доработки.
   3. Там, где есть полезные накопления, а внесение совместимых измемений приводит к проблемам, не отказываться полностью от совместимости, а предоставлять трансляцию там, где это оправдано объёмами накоплений.
3. Не стоит надменно отмахиваться от нежелательных требований пользователей. Полезно сделать попытку по корректному и тщательному объяснению мотивации.

Для уменьшения вероятности появления неудачных систем:

1. Применять имеющуюся теорию, связанную с задачами. Строго отличать теорию от волюнтаристских утверждений, гипотез и ремёсленных советов, которые, тем не менее, тоже могут быть полезными как направляющие, особенно, при отсутствии разработанной теории или её слишком большой сложности.
2. Не стоит полностью отказываться от проектирования подсистемы только потому что она малоприоритетна. Стоит предпринять хотя бы те усилия, которые практически ничего не стоят.
3. Крайне полезно учитывать изменяющиеся условия. Не нужно в планировании нового готовиться к устаревшим или стремительно устаревающим условиям.
4. С другой стороны, нужно учитывать, что прогресс и нововведения не тождественны. Стоит отказаться от нейтральных и тем более ухудшающих нововведений. Чтобы оказаться впереди, когда все бегут не туда, достаточно оставаться на месте. Например, в программировании алгоритмическая полнота позволяет бесконечно менять словарь основы, но по сути лишь ходя по кругу.