Знаете ли вы сколько неудобства есть в программных продуктах, потому что исторически сложилось? Исходя из современных правил рынка мы не можем долго разрабатывать продукт, полностью его продумывать и описывать разные граничные условия, коих может быть огромное множество, но даже если их все поработать, то есть огромный шанс, что получится не то... Гибкие методологии как раз и появились для того, чтобы дать короткую петлю обратной связи. Спринт ->релиз ->обратная связь. И все по кругу. Но тут требуется изначально продумывать гибкий и масштабируемый фундамент. Что тоже не всегда возможно. А когда мы получаем обратную связь, то нам, исправляя недочёты и вводя новый функционал, надо ещё позаботиться об обратной совместимости. Вряд ли бы вам понравилось, что при обновлении ПЛК необходимо переписать весь проект, а то он больше не работает. Для того, чтобы можно было исправить основные недочёты в фундаменте используют обычно мажорные версии или новые линейки оборудования. Так что если у вас возникнет вопрос, а почему тут так неудобно, то скорее всего-это исторически сложившаяся ситуация, которая держит обратную совместимость, возникшая по причине того, что не было достаточно времени или денег.