Мифический человеко-месяц

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

Но обратите внимание: целью применения инженерных принципов к разработке программного обеспечения в 1970-х годах было поднять качество, тестируемость, устойчивость и предсказуемость программных продуктов, а не обязательно производительность труда программистов.

Движущей силой использования при разработке программ принципов программной инженерии было опасение крупных аварий, к которым могла привести разработка все более сложных систем неуправляемыми художниками. [20]

Так что же случилось с производительностью?

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

Эд Йордон (Ed Yourdin) утверждает: «По моим наблюдениям, благодаря рабочим станциям и программным инструментам производительность увеличилась в пять раз.» Том Демарко (Tom DeMarco) считает, что «ваше ожидание десятикратного роста производительности за 10 лет благодаря целому набору технологий было оптимистичным: мне неизвестны организации, добившиеся роста

производительности на порядок.»

Программа в упаковке: покупайте, не надо разрабатывать. Одна из оценок «СПН» оказалась, я думаю, правильной: «Возникновение массового рынка является… наиболее глубокой долгосрочной тенденцией в разработке программного обеспечения». С точки зрения науки, программное обеспечение для массового рынка образует практически новую отрасль в сравнении с разработкой заказных программ как внутри фирмы, так и сторонними организациями. Когда счет проданных пакетов идет на миллионы или хотя бы на тысячи, главными проблемами становятся качество, своевременность, технические характеристики и стоимость поддержки, а не стоимость разработки, которая имеет такое большое значение при разработке заказных систем.

Электроинструмент для ума. Лучший способ повысить производительность труда программистов информационно-управляющих систем — это пойти в ближайший компьютерный магазин и купить уже готовым то, что они собираются разработать. Это не шутка: доступность дешевых и мощных коробочных программ удовлетворила многие из потребностей, ранее удовлетворявшихся заказными программами. Эти электроинструменты для ума больше похожи на электрическте дрели, пилы и шлифовальные машины, чем на большие и сложные производственные станки. Интеграция их в совместимые и перекрестно-связанные наборы, такие как Microsoft Works или лучше интегрированный ClarisWorks, обеспечивает огромную гибкость. И подобно домашней коллекции инструмента, в результате частого использования набольшого набора для разных задач вырабатываются привычные навыки. Такой инструмент подчеркивает простоту использования обычным пользователем, даже не профессионалом.

Иван Селин (Ivan Selin), глава American Management Systems писал мне в 1987 году:

Я хочу придраться к вашему утверждению, что в действительности пакеты не настолько изменились… Я думаю, что вы слишком легко отбросили главные следствия вашего замечания, что (программные пакеты) «могут быть немного более общими и немного лучше настраиваемыми, чем раньше, но не намного». Даже принимая это заявление за чистую монету, я полагаю, что пользователи расценивают пакеты, как обладающие более широкими возможностями и легче настраиваемые, и что такое восприятие делает пользователей более податливыми перед пакетами. В большинстве случаев, известных моей компании, не программисты, а (конечные) пользователи неохотно пользуются пакетами, покскольку думают, что лишатся важных возможностей и функций, а потому возможность легкой настройки весьма повышает для них привлекательность продукта.

Я думаю, что Селин совершенно прав: я недооценил как степень настраиваемости пакета, так и важность этого фактора.

Объектно-ориентированное программирование: а медна пуля не подойдет?

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

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