Заворачиваться в белые простыни,

и медленно, чтобы не вызвать паники, ползти на кладбище.

xkcd

Bad flu epidemics can hit young adults hardest because they provoke their powerful immune systems into overreaction, so to stay healthy spend the next few weeks drunk and sleep-deprived to keep yours suppressed.

Насущное

...

Итак, — хвала тебе, Чума,
Нам не страшна могилы тьма,
Нас не смутит твое призванье!
Бокалы пеним дружно мы
И девы-розы пьем дыханье, —
Быть может… полное Чумы!

О синдроме NIH

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

Этому есть объяснение, и самым кратким образом оно описано вот тут:
Ссылка

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

2. А тем, что этот кусок не сломается внезапно.

Никогда не сталкивались с тем, что вы приезжаете к важному заказчику ставить систему, а у вас сторонний модуль начинает кидать коней из-за несовместимости с какими-нибудь тонкими квантовыми эффектами настройки компа, ОС или инфраструктуры у оного заказчика?
Или когда система в силу особенностей реализации сетевых протоколов сразу же демонстрирует все грабли в настройках сети, типа глюков с фрагментацией пакетов и MRU.

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

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

Кстати, опять же о архитектуре систем

Как вам такая архитектура:

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

А дальше, судя по всему, разработчики прочитали что-то про OODB и сделали поверх нее иерархически-объектную базу данных, в которой данные в бинарном виде пишутся в строки(если строки не хватает - объект разбивается на несколько записей с Index=1,2,3...), а связи между объектами пишутся в одну универсальную таблицу на все случаи жизни.

Следующая версия этого всего, кстати, реализована в таком же стиле, но уже поверх Oracle, с сервером приложений на С++ и своим языком запросов к иерархиям и своим языком программирования :)