4 ms·
It's interesting to contrast this against the concepts in Team Topologies (https://teamtopologies.com/ https://teamtopologies.com/) - Kartik argues for better
by NAR8789 5y ago
It's interesting to contrast this against the concepts in Team Topologies (https://teamtopologies.com/ https://teamtopologies.com/)
- Kartik argues for better mutual understanding and additional communication
- Team Topologies states you should match system boundaries to team boundaries, specifically when cognitive and/or communications load have grown unmanageable due to team size and/or software complexity
On the surface, Kartik is arguing against abstractions and Team Topologies is arguing for abstractions, but both stances feel valid to me. It feels like there's a spectrum of tradeoffs here. Is this essentially an analogue to the tradeoffs of monolith vs services?
- For small teams, by all means keep abstractions low and communication high--monolithic systems and less division of labor is ideal and your team will gel better for it. Your team is probably not large enough to warrant either services or division of labor, so stick with the monolith.
- As an organization scales, you end up with an n^2 communication edges problem, and at this point division of labor is necessary to limit the cognitive and communications loads.
- mprovost 5y agoThis sounds like embracing Conway's Law [0] instead of observing it as emergent behaviour. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- NAR8789 5y agoPrecisely. Team Topologies strongly advocates the "Inverse Conway Maneuver", where you shape your team and communications structures towards your desired architecture.
- akkartik 5y ago"On the surface, Kartik is arguing against abstractions.." Nope. To clarify: https://news.ycombinator.com/item?id=30019146#30038853 https://news.ycombinator.com/item?id=30019146#30038853
- redredyupdy 5y agoAs someone who deals with APIs, I understand the point of abstraction. But when you start to deal with performance problems, a high level view of the internals can be invaluable for finding the problem. Something like a CRC diagram is invaluable http://www.agilemodeling.com/artifacts/crcModel.htm http://www.agilemodeling.com/artifacts/crcModel.htm To clarify, this then allows you to look inside of the API (to bunch of things talking over more APIs, yay microservices). Then you can see which bit might be causing the issue with the bit of the larger black box you are talking to
- ssivark 5y agoI think there needs to be one more aspect accounted for, and that is the domain. The domain might naturally push you towards larger (or smaller) blobs than you would otherwise anticipate, and in such cases I don’t think it makes sense to fight the domain — you have to adapt the team and software boundaries (map) to the ground reality (terrain), and find people who can function effectively with an atypical map — be it extra complexity or communication. I interpret Kartik’s point as stating that it’s counterproductive to split naturally integrated domains (terrain) for the convenience of map making.
- beckingz 5y agoAll abstractions are ultimately leaky, but you still need to have them to build large things.
- avgcorrection 5y agoAre all absolutes leaky?
- dpark 5y agoAbstractions are not always leaky. Often the “leaks” come from wanting to push past the bounds of the abstraction (for performance, additional capabilities, whatever). A good abstraction, if used as intended, needn’t always leak. People also often define “leaky” as “can break”, which is kind of unreasonable. The notion of a data stream across a network is an abstraction over many layers of complexity. People often say it’s leaky because of packet loss and failed connections, but that’s not a leaky abstraction unless you define the abstraction to not include a failure mode.
- deleted 5y ago[deleted]