Что является хорошим примером идеи или техники разработки программного обеспечения, которая была неудачной?

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

Например, я мог бы описать CORBA (и другие подобные технологии) как нечто, пытавшееся решить проблему связи между компонентами программного обеспечения. Многие считали необходимым определить контракты между различными компонентами. В конечном счете, HTTP + JSON решил проблему для масс и других различных механизмов RPC, таких как Thrift и Proto-bufs.

По сути, так же, как в мире за пределами компьютеров, идеи и технологии конкурируют за внимание, рычаги влияния и т. Д. Некоторые выигрывают, некоторые проигрывают; и некоторые могут казаться Победителем в течение некоторого времени, а затем исчезают в безвестности с появлением Следующего Большого. Это может иметь или не иметь ничего общего с тем, что было на самом деле лучше. Свидетель VHS против Betamax или недавней войны между различными форматами DVD.

CORBA была огромной, неудобной и сложной в использовании, но это было лучшее, что некоторые люди могли изобрести в то время (обратите внимание, что она была разработана до того, как World Wide Web - и HTTP, Java, XML, ... - стали широко известны). И это был также классический пример дизайна комитетом , где они втиснули каждую идею, чтобы удовлетворить всех, в конце концов делая ее бесполезно раздутой (по крайней мере, увиденной сегодняшними глазами). Не говоря уже о его цене, которая с появлением FOSS вскоре стала запретительной.

В конечном итоге HTTP + JSON решил проблему для масс

По крайней мере, для тех, кто не видел, чтобы пара подобных «окончательных решений» росла и в конечном итоге падала… Хорошо иметь в виду, что в то время было схожее мнение о CORBA ;-)

Я чувствую, что уместно привести цитату из книги «Взлет и падение CORBA» :

История CORBA - это история, которую компьютерная индустрия видела много раз, и вполне вероятно, что текущие усилия в области промежуточного программного обеспечения, в частности, веб-сервисов, воспроизведут аналогичную историю. [...]

В целом, процесс внедрения технологии OMG следует рассматривать как основную причину падения CORBA. Процесс поощряет разработку комитетов и политических маневров до такой степени, что трудно достичь технической посредственности, не говоря уже о техническом совершенстве. Более того, добавление разрозненных черт ведет к постепенному разрушению архитектурного видения. [...]

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

Теперь под другим углом: прочитав ваш термин «идеи масс», я подумал о совершенно разных вещах, чем CORBA или другие стандарты; Обычно это идея одного человека или небольшой группы. Я думал о пресловутых практиках / точках зрения, таких как «ковбойское кодирование», «кодируй и молись», «это работает на моей машине» и т. Д. Это ИМХО настоящие «идеи масс», так как это способ практически любого новичка. Разработчик инстинктивно начинает писать код. И они не правы, поскольку они не масштабируются ни в пространстве, ни во времени - таким способом нельзя создавать большие, поддерживаемые, расширяемые программы. Тем не менее, я чувствую, что, к сожалению, это все же норма, а не исключение, чтобы люди пытались работать таким образом в профессиональных магазинах по всему миру.

Другая крайность этого - идеи многих менеджеров и теоретиков о «правильном подходе» к разработке ЕО, проявляющиеся в методологиях большого М, таких как CMM, RUP, Waterfall и т. Д. Идея, лежащая в основе всего этого, заключается в том, что все, что вам нужно, это Правильный процесс, и он начнет автоматически производить качественное программное обеспечение детерминистическим способом, независимо от того, кто на самом деле разработчики. Обратите внимание, что в ту же игру можно играть и с помощью Agile-методов - это просто смена меток. Любой менеджер, который считает, что выбор (и сохранение) правильных членов для его / ее команды разработчиков менее важен, чем процесс разработки, неизбежно провалится, в зависимости от того, какой процесс произойдет. Тем не менее, эта вера в процесс все еще кажется распространенной - может быть, она все еще преподается в школах управления?

Частым примером того, как люди ошибаются, является модель водопада. Это схема стереотипной модели водопада, которая также появляется в статье Уинстона Ройса «Управление разработкой больших программных систем» .

Это изображение сопровождается этим текстом:

Я верю в эту концепцию, но реализация, описанная выше, является рискованной и вызывает сбой ... Фаза тестирования, которая происходит в конце цикла разработки, является первым событием, для которого время, хранилище, ввод / вывод, передачи и т. Д., опыт отличается от анализируемого. Эти явления не являются точно анализируемыми. Например, они не являются решениями стандартных уравнений в частных производных математической физики. Тем не менее, если эти явления не удовлетворяют различным внешним ограничениям, то неизбежно требуется серьезная модернизация. Простое восьмеричное исправление или повторение какого-то изолированного кода не решит подобных проблем. Необходимые изменения дизайна, вероятно, будут настолько разрушительными, что будут нарушены требования к программному обеспечению, на которых основан дизайн и которые обеспечивают обоснование всего. Либо требования должны быть изменены, либо требуется существенное изменение дизайна. Фактически процесс разработки вернулся к исходной точке, и можно ожидать 100-процентное превышение графика и / или затрат.

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

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

Автоматическая генерация кода из более высокого уровня абстракции или автоматическое программирование .

В статье в Википедии не хватает исторической информации, но это мечта менеджеров с тех пор, как программисты стали дороже компьютеров.

После разработки языков высокого уровня, таких как Fortran и Cobol, пришла разработка языков для специальных областей, таких как написание отчетов. Easytrieve и SAS были парой примеров.

В течение 1980-х инструменты CASE были в моде. CASE означает автоматизированное программирование. Считалось, что строгое применение инженерных принципов ускорит разработку программного обеспечения. Основной причиной того, что эти инструменты не завоевали популярность, помимо затрат, был высокий уровень стандартизации данных, необходимый для эффективной работы инструментов.

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

Аутсорсинг программирования в более дешевые места - это один из немногих оставшихся способов снижения затрат программистов. Проблемы с аутсорсингом включают проблемы коммуникации и проблемы спецификации.

Формальные Методы

Когда-то было предложено, чтобы программное обеспечение могло быть доказано правильным. (Идея состоит в том, что тестирование не может показать, что ошибок нет, но доказательства могли бы.) К сожалению, разработка доказательства для программы имеет ряд существенных недостатков:

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

Эта концепция была очень популярна в 70-х годах.

Связь: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods