2 ms·

Sign above Newton's desk: "If I have seen further it is by standing on the shoulders of Giants." We can strive for sustainability and autonomy, but we're forev

Sign above Newton's desk: "If I have seen further it is by standing on the shoulders of Giants." We can strive for sustainability and autonomy, but we're forever dependent on each other's work. As they say, it's turtles all the way down.

echelon 8y ago
Yes, but there is a lot of nuance here. Introducing dependencies is a quick way to get to market since you don't have to build a universe from scratch. Once you've gotten to market, you have to support your thing. This is when dependencies start to have a non-zero cost. When you'd rather spend engineering efforts on building new features, you instead have to do regular house cleaning to make sure your thing continues to work and have a happy upgrade path. The larger the engineering organization you work in, the more apparent this becomes. Smaller orgs can sometimes brush the ugly under the rug. Larger ones bump into issues constantly. I'd wager that 5% to 10% of engineering might be dealing with maintenance of dependencies. (fwiw, I'm mostly speaking in terms of my experience as a backend engineer.)
- _asummers 8y ago
  You are seeing to the heart of my argument. Thank you for that. I agree on the 5-10% mark, and find it's true even in smaller orgs that have a mature enough product. Once the product solidifies, having a bunch of different dependencies dictate which direction you can go is not in the best interest of the company, and should be reevaluated accordingly.
_asummers 8y ago
To thoroughly abuse the metaphor, you don't always want to go where the giant goes. Sometimes you would like to climb down and walk your own direction. Dependencies can take you near where you want to go, and if they can take you all the way there, terrific! Use them for as long as you can! But if you're not directing the giant, you're subject to its whims. And the more people standing on the giant's shoulders, yelling in its ears where they want it to go, the harder it is to make sure it's going where you want. At a certain point, this risk outweighs the rewards, and you adjust accordingly.

echelon 8y ago

Yes, but there is a lot of nuance here. Introducing dependencies is a quick way to get to market since you don't have to build a universe from scratch. Once you've gotten to market, you have to support your thing. This is when dependencies start to have a non-zero cost. When you'd rather spend engineering efforts on building new features, you instead have to do regular house cleaning to make sure your thing continues to work and have a happy upgrade path. The larger the engineering organization you work in, the more apparent this becomes. Smaller orgs can sometimes brush the ugly under the rug. Larger ones bump into issues constantly. I'd wager that 5% to 10% of engineering might be dealing with maintenance of dependencies. (fwiw, I'm mostly speaking in terms of my experience as a backend engineer.)

_asummers 8y ago
You are seeing to the heart of my argument. Thank you for that. I agree on the 5-10% mark, and find it's true even in smaller orgs that have a mature enough product. Once the product solidifies, having a bunch of different dependencies dictate which direction you can go is not in the best interest of the company, and should be reevaluated accordingly.

_asummers 8y ago

To thoroughly abuse the metaphor, you don't always want to go where the giant goes. Sometimes you would like to climb down and walk your own direction. Dependencies can take you near where you want to go, and if they can take you all the way there, terrific! Use them for as long as you can! But if you're not directing the giant, you're subject to its whims. And the more people standing on the giant's shoulders, yelling in its ears where they want it to go, the harder it is to make sure it's going where you want. At a certain point, this risk outweighs the rewards, and you adjust accordingly.