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

Забивалка данных пользователю быстрее надоест, чем автор сдуется :)
Этих "забивалок данных", простите, как говна...



Если бы компания использовала MS Access, то в любом случае найти компетентных специалистов на рынке найти не проблема. Для этого продукта есть как квалифицированные люди, так и огромная база знаний.

Это многогранный вопрос.

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

Кто вас пустит в чужую компанию, чтобы смотреть эти примеры? А слушать сказки вендора, это значит быть сказочно-наивным чукчей.



MS Access не предусматривает серьёзных решений. Это как раз та самая забивалка данных с минимальной автоматизацией, которая позволяет быстро и на коленке решать задачи. С самого начала моей трудовой деятельности, чего только на этом MS Access не делали, тестирование, учёт МТР, сбор сведений по энергоаудиту, опросы, сбор требований, рассылки и прочее... на MS Access всё делается на коленке за минимальное время, работает везде. Именно в таком ключе, для разовых вещей, для сбора данных, в условиях когда надо сделать "вчера" -- идеально.

Насчёт компетенций речь про минимальную поддержку и перенос экспертизы.

Аргумент про компетенции весомый в любые времена независимо от технологий. Если вы не можете найти специалиста на рынке для поддержки вашего продукта, вы встряли по самые помидоры. И в моей практике таких ситуаций наберётся ни один десяток. Есть даже случаи тупо банкроства вендора, и очень болезненных последствий для компании.



Демагогию можно разводить бесконечно. На моей практике MS Access для определённого круга задач -- крайне успешная хреновина. Прям найс. Совершенно не подходит для сложных приложений и для перспективы долговременного использования и развития. Но он и не рассчитан на это.

Пришёл на новый проект, .NET 4, архитектура говно, легаси просто трешак и ужас, все мыслимые и немыслимые нарушения принципов.

Год-полтора спустя, последний .NET Core, очереди, корпоративная шина сообщений, сервисы, контейнеры, нормальный CI/CD с девопсом, мониторинги, структурные логи, возможности активного профилирования, паттерны, адекватная архитектура и т.д. и т.п.

В общем, кто-то только ноет, а кто-то умеет и делает :)

Практика показывает, что решение, разрабатываемое под задачу -- на порядка два-три лучше, чем любой самый навороченный конструктор, которому место на свалке примерно через месяц после внедрения.



А чё там говорить? У нас есть 1С и целый огромный отдел программистов 1С, с несколькими командами разработки по направлениям, со своими процессами (аджайл, скрам/канбан и т.д.).

Без всего этого 1С -- абсолютно бесполезный мусор. Даже в самом минимальном применении в каком-нибудь самом маленьком магазинчике и то привлекается какой-то удалёнщик программист. Не часто, но привлекается, и без него 1С не жизнеспособен.

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

Проще и дешевле нанять специалиста, с почасовой оплатой. На 1С это сделать всегда можно. А на какой-нибудь DataExpress где такого найти?

Ваше утверждение не согласуется с практикой. Разрабатывать можно по-разному. Есть ещё кривые бизнес-процессы, которые не исправят никакой инструмент. Но именно разработка на ЯП позволяет автоматизировать самый упоротый бизнес.

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

Да тут всё просто. Если вендор предлагает конечное решение, и предлагает услуги по [настройке/доработке/разработке/да срать вообще чё он там будет делать, хоть в бубен стучать и коров в жертву приносить], чтобы решение оставалось конечным и это будет стоить разумных для компании денег -- велком.

Если вендор предлагает гоновконструктор в виде "сами настроите как вам надо" -- вендор идёт сразу нахер.



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

Про какую вы тенденцию говорите? 10 лет назад не было комбайнов? Не смешите. Потребность в обычных программистах и разработчиках увеличивается каждый год.



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



Это вы себя с Илоном сравниваете, а свой продукт со спейс драгоном? :))



Вы можете сменить область своей деятельности, если такие важные и значимые вещи у вас сидят в печёнках. Никто же вас не заставляет :)



Уверен, что когда-нибудь будет что-то такое возможно.
Хотя это напрямую противоречит формулировке "строгая формализация".
Да и строгая формализация по существу -- деградация, вектор вымирания.



Это вы говорите про "фатальный недостаток". Ага.
На самом деле у плохих решений есть определённые причины.

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

Построение архитектуры -- процесс вовсе не творческий. Творческий процесс, это реализация в жестких условиях с ограничениями.

У кого нет молодецкого задора, падают в линейную разработку.
В таком случае лучше сразу выбрать проект, который со всем обвесом вот прям сейчас "такой как надо".
А потом садишься и закрываешь одну за другой таски в джире :)

vovka3003,

так надо идти до конца :)

skachat.lds по аналогии PHP (personal home page) => LDS (lichnaya domashnyaya stranitsa)

:))

если что, это шутка, вникать не нужно )