State of The Ateam

In the beginning...

• We created the projects Mozilla needed
• We could go as deep on these projects as necessary
  
• No one asked us for anything because we'd never existed
• We drove the priorities, the staffing, the embedding etc.
• In other words, it was simpler, because things were simpler.
  

What happened?

• We were wildly successful.
• No, really.
• Mobile Automation Deployed (Maemo)
• Mobile Automation Nearly Deployed (Windows Mobile)
  
• Mobile Automation Deployed again (Android)
  
• nsIDOMWindowUtils Tests
• Gfxbot - crowd sourcing hardware acceleration testing
• Mozmill/Mozbase created
  
• JSReftests created and deployed
• Special Powers created to adapt to multi-process world
• And far more...
  

And then...

Drive the future

The best way to predict the future is to invent it. -- Theodore Hook

• B2G Automation and Marionette
• Mobile automation
• Bughunter
  
• JSReftests
• Mozbase
• Treeherder
  
• But, we've also relinquished this role as things have gotten hectic, especially due to the fact we don't delve as deep anymore

Clear metrics are a compass

Clear metrics define vision

• Mobile Automation Stability - shows how a simple metric coordinated effort among all the stakeholders and drove a project in the direction we needed it to go
  
• Signal From Noise - lack of  a clear metric prevented us from keeping the stakeholders on track and prevented us from creating a tight deliverable in the schedule we'd wanted.
• What are the metrics you should track for your projects?
  

Right People Involved

• Not only at the beginning
• In the middle
• And the end
• And most importantly, at the hand-off

But, they Are spectators

Aggressively follow dependencies

Buttons and zippers

• Build connections across the teams we work with
• We cannot rely merely on prioritization from managers, it's got to be all the way through the layers of a project (hence, buttons and zippers)

refuse to wait for validation

In our business, it is always better to ask for forgiveness rather than permission

• Define the goals with the stakeholders and then execute
• Often, the stakeholders have a very vague idea of what they want (if they have an idea at all).
  
• We are in the process of driving.
• We are the people maintaining this code
• We are the people deciding how it integrates with other projects
• B2G automation started well in this vein, and then lost its way due to letting others set our priorities for us
  

Create Connective tissue

Pay down technical Debt

• Seek out natural integration points with other tools during design and implementation
  
• Find high impact places to fill in debt when working on a component
• But, don't drown yourself in minutiae.
• One example of this done poorly is how every harness has a different log format, even ones we created from scratch.
• One example of this done well is Eideticker
  

Go deep, teach the world to fish

service vs development

• It's always going to be a balance
• Everything we make should be extensible, a building block - we are really good at this nowadays.
  
• And, while extensible is incredible, extensible and easy to extend is better.
• Good example: Marionette, Bugzilla's REST API
  

Complete the circle to stay on Course

Those who do not learn from history are doomed to repeat it

• Our projects are long-running
• Our systems are complex
• We should continually look at the problem we're solving from the user's perspective
• We need to encourage, plan, and perform post-mortems on our projects in order to continually course correct
• Invite the stakeholders to the post-mortems.
  

We are the most valued services team at Mozilla

 And, we can always improve.