3 ms·
There's an interplay between them. Communication always has a cost; there are certainly things you can do to the constant factors, but in a 100-person engineeri
by geofft 6y ago
There's an interplay between them. Communication always has a cost; there are certainly things you can do to the constant factors, but in a 100-person engineering organization with 20 teams, it's fundamentally going to be much easier for an engineer on one team to write a build system (or pre-merge CI flow, or whatever) that meets the needs of their four teammates working on the same code than one that meets the needs of all 20 teams.
The advantage of a running, pre-existing system (and the theoretical advantage of an off-the-shelf system like this that you can supposedly turn into a running system) is that it's been built to satisfy most of the needs of a wide variety of developers working on all sorts of things, and so each engineer on each of those teams that says "All right, I'll spend some time thinking about how we build and release code" is incentivized to start from the common starting point, even if they have to customize it. That means that if two or three teams end up working on similar-enough projects down the line, the shared tooling can actually support communication between the teams. Without the shared tooling, they can communicate all they want, but it won't be rational for any team to abandon its existing tooling. (And of course you need the communication too - both are required.)
- gabereiser 6y agoI hear you. I do. How do you get 20 teams working on disparate codebases, and probably languages, to share their knowledge across teams? How does a team working on Java benefit from something someone found in Django from another side of the company? Organizations need standards. Developers require it. We want the thing we are programming against to not change right? We want our codebase to build when we say build. All tests green. Happy. Productive. Engineering leadership needs to organize standards around engineering culture and tooling, it could be championed by a team that did it, or by research. It doesn't matter. What matters is that leadership facilitates communication into what is working, what isn't, why, and what can we do about it? At the micro-level, tools help, no doubt about it. At an org level, communication helps (documentation is a form...). Even if using different tooling, concepts and strategies are the same. This isn't to take away from the argument that this tool the OP posted is pretty awesome. If you want change, be the change. Evangelize the tool through your org, not just your team. If your org is silo'd, break those barriers down with a friendly lunch-n-learn or lightning talks session. We tout empathy for our customers, how about empathy for our coworkers too? Others may have the same pain...