В процессе разработки программного продукта программисты пишут код, который затем компилируется (интерпретируется) в работающую программу. Обычно главным критерием качества работы разработчиков является результат: на сколько хорошо программа выполняет свою функцию. А арбитрами в вопросе оценки результата являются пользователи, которые голосуют в том числе и кошельком.

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

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

На практике даже в случае больших сложных и долгосрочных программных проектов встречается абсолютно наплевательское отношение к архитектуре и коду. Особенно это свойственно аутсорсинговым проектам, где пишут «не для себя». Здесь главная задача — именно результат. Работу сдал, деньги получил и забыл. А с программой потом будут мучаться уже другие. Причем, это правило действует как в масштабе фирмы-аутсорсера, так и в масштабе конкретного разработчика.

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

Выходит, что чем меньше на проекте людей, тем выше должна быть их квалификация для получения того же результата. А как следствие — тем качественнее будут внутренности программы. В случае работы на перспективу такой подход получается выгоднее, так как наработав хорошую базу, ее легко и относительно недорого масштабировать, сопровождать, расширять. Этот подход и стараются применять компании, пишущие код для себя. Именно поэтому, в крупных компаниях типа Гугла, Яндекса работают преимущественно очень высококвалифицированные кадры. Каждый сотрудник этих компаний в состоянии решать сложные комплексные вопросы.

С другой стороны, когда необходимо удешевить стоимость разработки, нужны люди которые «за дешево» сделают так, чтобы работало как хочет заказчик. Чем больше хочет заказчик, тем больше надо таких людей. От них не требуется решения сложных вопросов, они должны лишь уметь выполнить относительно простое четко поставленное задание. Именно поэтому на аутсорсерских конторах часто водятся буквально стада средних и слабых разработчиков.

Но справедливости ради, надо заметить, что в последнее время аутсорсеры стараются выходить на путь качества, а не количества. Многие заказчики стали понимать, что им подсовывают каку и искать более серьезных партнеров. Так что похоже на то, что в среднесрочной перспективе 80% (по принципу Паретто) разработок должны быть по качеству архитектуры и кода выше среднего.

Получается, что мы имеем два диаметрально противоположных принципа разработки кода и архитектуры ПО:

• количественный: много слабых разработчиков пишут много кода — получаем ожидаемый результат;
• качественный: мало сильных разработчиков пишут среднее количества кода — получаем такой же ожидаемый результат.

А что будет, если нанять много сильных разработчиков? А тоже самое, что и в случае малого количества слабых — результат будет другой. Другими словами: чтобы получить одну и ту же программу по функционалу на выходе нужно либо мало сильных, либо много слабых разработчиков.

Самое, пожалуй, невыгодное в этом случае среднее количество средних разработчиков, потому что результат будет относительно дорогой, но не очень качественный.

Все написанное выше является моим ИМХО и основано на личных наблюдениях. Контраргументы принимаются и тема подлежит обсуждению для выяснения истины.