On Fri, Nov 20, 2015 at 1:01 PM, Benjamin Francis <[email protected]> wrote:
> On 20 November 2015 at 10:18, Vivien Nicolas <[email protected]> wrote: > >> >> Having a dedicated set of people that works on it, is definitively part >> of the plan that nobody knows but is the companion of the new architecture >> proposal: Arch >> <https://wiki.mozilla.org/Gaia/Architecture_Transition_Proposal#Toolkit_Team> >> >> On the transition plan, I think the front end/back end split makes > perfect sense from a technical point of view, but I'm very concerned about > the idea of reorganising our 100+ person team into a front end team, back > end teams and a toolkit team. This organisational structure seems like it > would be a nightmare for our EPMs as virtually every single feature we > develop would have cross-team dependencies. Cross-team dependencies kill > our productivity, especially given the distributed nature of our teams > across timezones. It's bad enough having Gecko dependencies for Gaia > features,representing another level of architectural abstraction in our > organisational structure seems like a recipe for not moving anywhere fast. > > Let me give you an example of a user story, "As a user I want to create a > playlist of songs". Implementing this feature would require an addition to > the API (media back end team) and also an addition to the UI (front end > team). The front end team now has dependencies on the back end team and has > to file user stories in their backlog like "As a Gaia developer I want to > add a playlist", "As a Gaia developer I want to remove a playlist", "As a > Gaia developer I want to add a song to a playlist" etc. Now imagine this > new UI requires a new or modified web component - the front end team has a > dependency on the Toolkit team. Now imagine it requires some platform > support for streaming M3U playlists, the back end team now has a dependency > of Gecko. All these pieces have to be implemented by all of these separate > teams in their separate timezones with clearly defined interfaces for one > feature to be completed. Then Product or UX change the requirements > (inevitable) and the whole process has to start again! > > I think the new architecture does give us an opportunity to make a change > to the way we manage our teams. It gives us the freedom to create even more > autonomous cross-functional teams like the media team, productivity team > and communications team who have less dependencies on the wider project and > can move fast to deliver updates on their own timescale. Whilst I agree > with the front end/back end split and shared components, I think directly > mapping the architecture onto our organisational structure is maybe a bit > simplistic and could be a recipe for disaster. My view is that what we need > is agile, autonomous, cross-functional teams who specialist in one product > area. We probably need the existing specialists in those apps to carry out > the front end/back end split in the first place anyway. I wouldn't have a > clue how to create a front end or back end for our music app, but the media > team does. > I'm pretty sure nobody is confident enough is my re-org plan :) So while I will be happy to discuss about it, do not take it as a real plan, just as my personal view on how things should be. I feel strongly that the organisation should be mirroring the architecture and vice-versa. But while I will be happy to discuss about it, do you mind if we spawn a dedicated thread. Not to kill the conversation but otherwise I believe this particular discussion will be flood! > > One other more technical comment is that one part of the architecture I > don't understand is why our "back end" pieces and our "data sync" service > are not the same thing. Wouldn't web apps usually work by having a > server-side REST API where all the data is stored, then multiple front ends > on different form factors which talk to that API and cache data on the > client? Why are we creating a web API which stores its data locally then > syncs via a separate service? Is that just applying native Firefox app > development thinking to web development? > Fernando or Francisco will likely explain it much better than I. But basically Data Sync to a remote server has its own concerns, like what is the server infrastructure, which types of datas to we want first, etc.. to be its own project. If you are interested in details there is a Firefox OS Data Sync <https://wiki.mozilla.org/Firefox_OS_Data_Sync> wiki page and the tracking bug is bug 1161657. So you can look at Data Sync as a one of our shared toolkit library, which may be used by the backend. While backend often refers to the specific app business logic in this thread - even if the communication mechanism is part of the toolkit under the bridge.js library. Hope it helps. > > BTW, thanks for having this discussion in the open :) > > Ben > > > <https://lists.mozilla.org/listinfo/dev-fxos> >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
