Simple example: You have two teams that work on different systems. A feature needs to be built that crosses the two systems. Do you: a) Build a temporary team

Simple example: You have two teams that work on different systems. A feature needs to be built that crosses the two systems. Do you: a) Build a temporary team with 2 developers from each team. b) Create a spec and hand it to Team 1. Team 1 adds an API for Team 2 to consume. Team 2 gets the API spec from Team 1 and integrates. In situation (a), it's likely your solution will blur the line between system 1 and system 2. The solution will be very specific and implementation details on each side will be blurred together influencing the result. In situation (b), it's likely that the API on system 1 is more generic and less coupled to the implementation details of system 2. Situation (a) is generally faster to market. Situation (b) is generally easier to maintain, but can be much, much slower. A specific example I've seen recently is a web server written in C doing string manipulation and a javascript client consuming data from this API. If I'm working closely with the frontend developer, I'm going to say "How about I send you the data raw, and you split on this sequence". Splitting in javascript is much simpler than strtok_r and as a bonus I offload the processing to the client. From a development standpoint, it takes 2 minutes to coordinate. If I'm not working with the frontend team, then I'm probably going to go through the trouble of doing the string manipulation server side. Does that make sense? (not the design itself, but as an explanation of how communication influences design).