| Very good writing. A few comments: "as a product you’re betting that your API design is robust enough that groups can remotely work at their own pace or velocity. The core question is why would you want to constrain yourself in this way? " I am not certain which constraints are implied here - to me an API that facilitates such a work is simple and understandable which to me are admirable qualities. Perhaps the challenge then is to split the architecture into small enough testable units which communicate through the simple APIs? Once again, this sounds great. But in practice simplicity, understandability and good architecture are reachable by experience or trial and error so I suppose it would require either a situation were a known pattern is reapplied to new business requirements or one where there is ample time for designing and prototyping with these qualities as explicit design constraints. "how to balance resources on each side of the API." I suppose the best situation would be then an API that supports a directed graph of rensponsibilities. Like a plug in system, for instance? "...however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. " So I suppose to make remote working work software architecture and team management need to be linked on a very intimate level? This would be nice in any situation, I think |