Какое худшее технологическое решение вы когда-либо видели? [закрыто]

10

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

user3463
источник

Ответы:

22

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

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

Другой разработчик : «О, вы не забыли, на этом поле было уникальное ограничение. Я просто удалил его».

Я : "Почему ты это удалил?"

Другой разработчик : «Я сделал это несколько недель назад. Я получал файлы данных от клиента, и они не импортировали, потому что уникальное ограничение блокировало новые данные. Поэтому я удалил ограничение, чтобы закончить его импорт».

Я: "Вы перестали считать, что, возможно, возникла проблема, если мы получали новые данные, которые перекрывались с существующими данными, и подумали об упоминании их кому-либо перед их импортом?"

Другой разработчик : (пустой взгляд)

Я : Facepalm.

JohnFx
источник
Это просто больно.
8

Использование Visual Sourcesafe

mpenrow
источник
Теперь это просто жестоко.
Обратите внимание на себя - придумайте имя
7

Не уверен, что это считается технологическим решением, но я отвечал за CMS-подобный веб-сайт для управления документами, написанный на PHP в течение четырех лет. В течение этих лет я несколько раз пытался заставить людей (менеджеров, пользователей, тех, кто запрашивает функции), возможно, возможно, например, возможно , рассмотреть возможность собраться вместе и подумать о требованиях и будущем направлении вещей. Это никогда не происходило. Это всегда было «добавить эту функцию», «добавить эту функцию», и все были в блаженном неведении обо всех различных способах использования сайта всеми остальными . К тому времени, когда я ушел, это стало огромным беспорядком взаимосвязанных, но не связанных функций, и я был единственным во всей компании, кто знал каждую функцию. Теперь никто не делает. Mwahaha.

Timwi
источник
Время получить консультанта на борту!
Кирк Бродхерст
4

Переписать систему голосовой почты класса Telco.

Предыдущая система работала в Unix, и примерно в конце 90-х появилась технология Microsoft COM. Многие разработчики работали над этой новой системой на базе NT. После долгих усилий его производительность все еще не достигла уровня производительности системы Unix, и крупный покупатель, купивший эту новую систему, был взбешен. Компания должна была быть продана, и некоторые люди должны были покинуть компанию.

Это было некрасиво. Все это произошло примерно за два года до того, как Джоэл написал свою статью: То, чего никогда не следует делать, часть I

grokus
источник
3

Принятие внешней библиотеки (в данном случае Spring RCP ) до ее первой версии на основе снимка SVN. В значительной степени гарантировано, что проект закончится более или менее мертвым, и вы окажетесь привязанным к трупу. Ну, в нашем случае могло быть и хуже. Все еще большой риск.

Carlos
источник
Аааа, ты только что напомнил мне о другой части моего прошлого, я бы предпочел забыть. Я унаследовал часть проекта (того же проекта, который упоминал в своем ответе), который был построен на снимке Spring RCP. Я никогда не мог понять почему. Кажется, это не добавляло ничего, кроме хлопот.
Дэн Дайер
3

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

В большинстве случаев такого рода проблемы, с которыми я сталкивался, связаны с принятием непроверенной / незрелой технологии, часто потому, что кто-то влиятельный с технической стороны является сторонником возобновляемой разработки.

Дэн Дайер
источник
1

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

В феврале этого года они объявили, что новая система будет основана на Sharepoint 2010. Хотите догадаться, почему? Потому что, внезапно, это было имя, известное Фармасу, и им было удобно!
Посмотрим, что принесет 2012 год!

\\ uSlackr

uSlackr
источник
0

Написание современных операционных систем на C / C ++. Со времен Morris Worm (в конце 80-х) мы знали, что это совершенно неподходящий язык для создания сетевого программного обеспечения, но это никого не остановило, что в основном сводится к преступной халатности IMO.

Мейсон Уилер
источник
5
-1 Это я или примерно в 5-й или 6-й раз вы писали о том, что C - ошибка? FUD утомляет. Тот факт, что вы не можете кодировать С, не допустив ошибку безопасности, не означает, что другие люди не могут. Вы не можете ненавидеть язык, основываясь на том, какие плохие практики возможны.
альтернатива
2
Это является FUD утверждать , что тот факт , что «C плохой язык» является объективным общеизвестно.
альтернатива
2
@mathepic: Я говорил что-то столь туманное, как «плохой язык»? Я сказал, что это совсем не подходит для создания программ, таких как операционные системы, которые имеют требования безопасности. И это как объективный факт, так и общеизвестный.
Мейсон Уилер
6
@mathepic: Я с Мэйсоном об этом. Широко известно и принято, что обработка строк в C вызывает переполнение буфера, а в надлежащем языке программирования - нет . Неважно, насколько хорошо вы думаете, что «надежно и последовательно кодируете C безопасно» (pff), язык, который излишне увеличивает количество ошибок, является плохим языком.
Тимви
3
@Timwi: оригинальный ответ сказал "C / C ++". В C ++ обработка строк не вызывает переполнения буфера. Не то чтобы я большой поклонник std::string, но это работает, и вместе с шаблонами классов контейнеров может устранить большой класс потенциальных ошибок.
Дэвид Торнли
0

Что я увидел....

Еще в 1980-х годах была компания под названием Prime, которая производила компьютеры с версией базы данных Pick и BASIC. Пользовательский отдел того места, где я работал в то время, когда покупал, был абсолютно убежден, что это сэкономит им кучу денег, что они получат необходимую обработку и результаты с одним бизнес-аналитиком за четверть времени. Прошло совсем немного времени, прежде чем появились четыре программиста, занятых полный рабочий день, и отставание в работе.

Большая ошибка в оценке того, что технология сделает для них.

Дэвид Торнли
источник
1
Старый добрый пик. Я всегда сомневался в том, чтобы называть OS / Database / Programming language в честь себя. (например, Дик Пик)
Билл