4 ms·

There’s definitely a middle ground between ‘we need to know how this plan will overcome every obstacle we will encounter before we even begin’ and ‘there won’t

There’s definitely a middle ground between ‘we need to know how this plan will overcome every obstacle we will encounter before we even begin’ and ‘there won’t be any obstacles what do you mean?’ I always want to have a sense that the plan gives us realistic options for dealing with the obstacles. And that doesn’t just mean technical options - we’ll need to have the people to tackle it too. Eg it’s not great if the plan involves a bunch of teams running servers, and while technically there are obviously ways for all those teams to operate and scale those servers, if they don’t have the time or skills to do so then that option of having the teams run stuff is not really realistic. But on the other hand planning a careful course that navigates round every obstacle is just as bad because 1) the obstacles will likely have moved by the time you get there (eg we spend ages figuring out how teams on legacy JS will be affected by the project only to find by the time we get there everyone has already moved to typescript and all that prep was YAGNI). And 2) there are probably obstacles right in the path you’ve carefully chosen that you don’t know about yet and when you hit them your plan will grind to a halt because there was only one way planned and this was it. We’re reading a cartoon podcast description of a complex architectural debate here though, so who knows which of these straw men was actually close to what was happening in LinkedIn.

chriskrycho 3y ago
This is a great summary. Obviously I bring my own perspective to this, because, well… it happened to me, and I “lost”. But my read was that the folks I disagreed with and ultimately parted ways with were falling into the bucket you label ‘there won’t be any obstacles what do you mean?’. The tradeoff around “do we migrate to TS?” is a great example here, by the way. A huge part of our decision-making last year around the big app at LinkedIn was on exactly that question: If you are going to stop and throw the entire thing away, you should waste exactly zero time migrating any of it. On the other hand, if the thing is going to be migrated incrementally, you should accelerate the TS effort because it will make it so much easier to code-mod the code base. (I don’t agree that it’s a “cartoon” podcast description, but it is definitely extremely compressed and Adam and I chose to focus on the personal dynamics over the technical details, because diving into the latter would have made for a 5-hour episode. Also: it’s really tricky to do any of this kind of public discussion in a way that doesn’t just end up reading as a one-sided self-defense!)

chriskrycho 3y ago

This is a great summary. Obviously I bring my own perspective to this, because, well… it happened to me, and I “lost”. But my read was that the folks I disagreed with and ultimately parted ways with were falling into the bucket you label ‘there won’t be any obstacles what do you mean?’. The tradeoff around “do we migrate to TS?” is a great example here, by the way. A huge part of our decision-making last year around the big app at LinkedIn was on exactly that question: If you are going to stop and throw the entire thing away, you should waste exactly zero time migrating any of it. On the other hand, if the thing is going to be migrated incrementally, you should accelerate the TS effort because it will make it so much easier to code-mod the code base. (I don’t agree that it’s a “cartoon” podcast description, but it is definitely extremely compressed and Adam and I chose to focus on the personal dynamics over the technical details, because diving into the latter would have made for a 5-hour episode. Also: it’s really tricky to do any of this kind of public discussion in a way that doesn’t just end up reading as a one-sided self-defense!)