3 ms·
Without watching the video ... I can tell you in the olden days when RCS still stalked the Earth and our dev teams were in London, New York and Tokyo, and bandw
by DamonHD 9y ago
Without watching the video ... I can tell you in the olden days when RCS still stalked the Earth and our dev teams were in London, New York and Tokyo, and bandwidth was thin ...
We very simply tried to divide the work and the functionality along geographic lines so that you were likely within shouting distance of anyone that could break the immediate stuff you were working on.
Later we added some central coordination of the stack of things as they went together since there often were ugly issues about getting new features integrated all in one go through the whole stack for example.
In any case, the lesson here was that while there are no complete answers, for us refactoring functionality coarsely along team lines worked. It may seem backwards, but we got a lot done.
(This in a world where branching was very painful, so at most we had it for production bug-fixes as I recall.)
- yuvalkor 9y agodividing the work between teams worked at first but as product grown it started to have dependencies between teams and it got messy. Eventually you need to implement functionality across team areas. one team is assigned to implement it and when it breaks in other areas - that team needs to ask the other teams to fix it... in short, dividing the product to different teams is not an optimal solution.