Баги в интерфейсе - это не так страшно. Страшнее, когда баги есть в алгоритме или методе отчётностей или начислиений. Сам был свидетелем подобных вещей. Обычно в гос-конторах над программистами нет тестировщиков и нет контроля качества. Я общался на такую тему с одним. Говорю - парень. А тебе не совестно вообще что вы такое лабаете? Оптимизации - ноль. Базу укладываете на лопатки одним единственным отчётом. А он мне молча показывает план. А там написано, что в месяц он должен нах*ячить некоторое количество packages или модулей. И вопросы оптимизации его начальство не *бут. Я говорю *бут наше. Весь отдел эксплуатации. Пускай они договорятся. От отвечает *уй. Никогда они не договорятся.

Забавно что со сторонними подрядчиками практически та-же самая история. Только feedback еще хуже. Надавить на бабло невозможно. Договор на поддержку отражает только общие части и никак не регламентирует глубину этой поддержки и сроки. Разорвать договор невозможно. Те чуваки, которые его заключали уже давно умыли ручки и к эксплуатации никакого отношения не имеют. А что можем сделать мы? В самом лучшем случае, тех-директора центров могут писать жалобные письма или докладные на адрес главного, и тот... немного почесав ж* позвонит и поинтересуется... а почему собсно.. и то после такого разговора даст кренделей своим еще больше.... дескать х*рово работаете. Не умеете вести диалог.

Неоднократно замечал у разрабочтков PL/SQL странную привычку - декларировать много параметров в процедурах пакетов. Что-то вроде

Причём из списка 20 аргументов использовались только 2-3.

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