I’ve felt like Cassandra whenever I’ve pointed out how product structure, team structure, or process structure was causing development to bog down.<p>I’ve seen cases where we were building models that took a certain amount of calendar time and if we only managing punchclock time we wouldn’t start building early enough.<p>Similarly I think it’s a problem if you have 12 maven projects and what management thinks is a ‘simple’ change involves touching 7 of them, I think an objective measure of a good design is that changes can frequently be confined to a small number of files and directories.<p>Most of all the popular ‘heavy JS frontend’ architecture is frequently disastrous not for technical reasons but for the wetware problems of coordinating a front end and a back end team which would turn 2 sprints into 3 sprints without any bungling but add just a little bungling multiplied by the team structure and 2 sprints become 7 or 8 sprints. (The worst thing about it is that because people feel disempowered to do anything about it there is this ‘groupthink’ that causes people to neither perceive the bungling <i>or</i> the amplification of bungling by sprints that transform 2 day delays into 2 week delays)