> Being able to refactor/change one part of the code without being afraid that something else might break is an excellent reason to use a framework.
Yep. It's also more or less essential when something is subcontracted, like this was. In this case I think there were hard-working, competent developers who were burned by the original spec hiding a lot of undiscovered complexity, and what would have been a really good piece of work went inevitably quite wrong. The subcontractors clearly desperately tried to finish it within their parameters, and the result is something that met most of the spec but satisfied nobody.
(The framework decision they made wrong was in the front end, because there they made the disastrous choice to run with Angular 1.x -- which was presumably an in-house skill -- and not push to at least use 2.x. The resulting project is the precise kind of agony that Angular 1.x is famed for.)
Yep. It's also more or less essential when something is subcontracted, like this was. In this case I think there were hard-working, competent developers who were burned by the original spec hiding a lot of undiscovered complexity, and what would have been a really good piece of work went inevitably quite wrong. The subcontractors clearly desperately tried to finish it within their parameters, and the result is something that met most of the spec but satisfied nobody.
(The framework decision they made wrong was in the front end, because there they made the disastrous choice to run with Angular 1.x -- which was presumably an in-house skill -- and not push to at least use 2.x. The resulting project is the precise kind of agony that Angular 1.x is famed for.)