I’ve felt like Cassandra whenever I’ve pointed out how product structure, team structure, or process structure was causing development to bog down.
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.
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.
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 or the amplification of bungling by sprints that transform 2 day delays into 2 week delays)
I’ve felt like Cassandra whenever I’ve pointed out how product structure, team structure, or process structure was causing development to bog down.
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.
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.
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 or the amplification of bungling by sprints that transform 2 day delays into 2 week delays)
One of my favorite stories of a failed dependency concerns video support for Flickr.
My recollection is that the Flickr team had been told they should to hold off on building this and wait for technology developed by Yahoo! Video.
After six months or so of waiting, a Flickr engineer knocked something together using ffmpeg over a weekend.