Я называю "административным" методом две совершенно несвязанные вещи. Наверное, для этих методов есть какие-то официальные названия. Если знаете — сообщите.
1. Вместо изменения алгоритма надо поменять железо. Типовая ситуация: не хватает памяти. Если памяти не хватает чуть-чуть, то можно и оптимизацией кода заняться. Но бывает, когда текущее аппаратное решение явно слишком слабо для получения результата. А бывает, когда доставить в комп памяти проще, чем что-то там менять.
Проблемы: если железо недостаточно мощное, то всё нормально. Но бывают другие ситуации, схемотехнические, к примеру, когда что-то не так подсоединено. Когда электронная часть работает не совсем так, как ожидалось. И разработчики железа, и начальство, как правило не хотят вносить изменений в конструкцию, потому что это долго, дорого и неудобно. Тут надо понимать, что многие аппаратные недостатки действительно можно исправить программно, но эти исправления в длинной перспективе могут аукнуться. Это надо внимательно анализировать. В ситуации с изменением железа программист оказывается жертвой, если ему не удастся пробить изменение железа.
2. Вместо изменения алгоритма делается пометка в руководстве: при возникновении такой-то ситуации пользователь должен делать то-то.
Проблемы: если в первом случае жертвой был программист, то тут жертвой становится пользователь. Пользователь может быть не слишком квалифицированным, либо отвлечься на птичку, и вот он уже жмёт на кнопку "удалить всё", а потом удивляется. А мы ему тыкаем в инструкцию: всё правильно, у вас ошибка оператора.
Ну и вот, таких отсылок в инструкциях должно быть минимальное количество. Если возможность есть, программа должна сама понять, что происходит, и либо самой сделать то, что надо, либо предложить пользователю варианты действий. Если программа не имеет технической возможности что-то сделать, то информация об этом должна выводиться сразу на экран, а не просто быть где-то написанной на 55-й странице, которую никто не читал. И только в исключительных случаях надо указывать необходимые действия в инструкции.
Эти два метода имеют абсолютно разную направленность, но у них есть сходство: перекладывание ответственности с программиста на других лиц. И если первый метод хорош, потому что он чаще всего улучшает работу ПО (без затрат программиста, лол), то второй метод наоборот — делает ПО менее надёжным за счёт увеличения человеческого фактора. Каждый раз перед применением второго метода надо внимательно думать.