I thought this was an interesting essay, though I'm not sure I agree with all of it.
I do wonder if he's proposing somewhat of a false dilemma here. Maybe it's possible to ship often _and_ have high quality _and_ make big changes when needed?
Shipping often just means you have a lot of chances to work out and automate that pipeline so that it mostly works. Shipping infrequently means every time you ship, it's broken.
I think this is somewhat independent of team size -- companies with large teams have large teams because the product is very complex and they want to iterate quickly; not only (or really?) because they want to ship every week.
That being said, I don't do mobile, but in terms of deploying a webapp, I want it to be reliable, very fast (<1m), and easy (type a command into Slack). If you have such a system, it lets you work however is convenient -- single small team, many (siloed) small teams, one large team -- it doesn't really matter. It's amazingly freeing when the act of merging and shipping code is just second thought -- something that just always works. Even shipping changes to the deployment system itself becomes very fast -- so you can iterate and constantly make it better as well.
2 comments
[ 4.5 ms ] story [ 16.3 ms ] threadI do wonder if he's proposing somewhat of a false dilemma here. Maybe it's possible to ship often _and_ have high quality _and_ make big changes when needed?
I think this is somewhat independent of team size -- companies with large teams have large teams because the product is very complex and they want to iterate quickly; not only (or really?) because they want to ship every week.
That being said, I don't do mobile, but in terms of deploying a webapp, I want it to be reliable, very fast (<1m), and easy (type a command into Slack). If you have such a system, it lets you work however is convenient -- single small team, many (siloed) small teams, one large team -- it doesn't really matter. It's amazingly freeing when the act of merging and shipping code is just second thought -- something that just always works. Even shipping changes to the deployment system itself becomes very fast -- so you can iterate and constantly make it better as well.