Mobile/FN14PostMortem

Fennec Native Post Mortem

Process

1. Questionnaire
2. In-Person Discussion
3. Report on Lessons Learned

Goals and Guidelines

1. We all understand that the goal is improving the next project, so we’ll try to be as honest as we can
2. Everyone gets a chance to talk and all perceptions are equally valuable
3. Respectful listening is key
4. Acknowledging both what went well and what we could do better next time

Questionnaire Results

Proud?

• 7 of 9 were proud
  • 2 Neutral parties stated so b/c of quality and lack of product differentiation

#1 Frustrating Thing?

• Communication got lost, directed to incorrect person, or came in too late
• Lack of Product direction and competition for resources for different horizons; need staff new initiatives vs. drain current resources
• Work life balance was skewed; too many late nights
• Unexpected l10n issues at the end
• Nebulous ship criteria, didn't have a clear picture of "what it would take to ship"

Notable: "I feel that any solid software product has two prerequisites: (1) a solid understanding of the required behaviour and (2) code that fulfils that behaviour in a way that is easy to understand. We have (1) but not (2), and that was really frustrating to me - knowing how much better our product could be (and how much faster we could be moving) if we did things a little differently."

Proposed Solutions

• More vis into bug burndown and priority
• More consensus. Build a "drivers" group earlier in the cycle
• Needs single source of truth
• Hire resources for product development happening in parallel

NB: "Spend some more time up-front doing some architectural design on the codebase rather than hacking features into a semi-working state and filing follow-up bugs for the rest. Sure, some of the features are big and complex and require multiple bugs to track all the work, but a lot of them are simple enough that one well-designed patch would do the job, if our code was structured better and had well-defined invariants. Instead we have patch after patch after patch just fixing up behaviour that wasn't done right the first time"

NB: "Make honest assessments of our place in the market, make deliberate choices to act on them, and fully commit to those gambles organization-wide."

Most Gratifying?

• Shipping
• 5 Star Reviews
• Making something that seemed impossible actually happen
• Level of trust and professionalism across teams was amazing

NB: "Spend some more time up-front doing some architectural design on the codebase rather than hacking features into a semi-working state and filing follow-up bugs for the rest. Sure, some of the features are big and complex and require multiple bugs to track all the work, but a lot of them are simple enough that one well-designed patch would do the job, if our code was structured better and had well-defined invariants. Instead we have patch after patch after patch just fixing up behaviour that wasn't done right the first time"

Comments & Open Discussion

• There was inter-team engineering drama in the early months that I would like discussed. I would not like to go through that again, so I'd like to talk about how to prevent it.

• This questionnaire doesnt feel entirely fair because we had different problems at different points. At one point I do think we had too little involvement from certain teams (such as l10n), but then we fixed it and it went well, how do I record that?

• We'll be really lucky if we can reproduce the success of MTD and daily mobile triage in B2G 1.0

• "Re engineering resources: it's not just a matter of throwing people at the problem. (In fact, I turned down offers, because it was quicker for me to do the work than to ramp up someone new. That's changed now.)

• We need a more modular codebase, and the maturity that comes with time. And better tests. If we don't have that, more engineers just end up getting blocked, frustrated, or even slowing down the whole project by introducing coordination overhead. (That is, we'd get ""man monthed"" to death.)

• We can always use more QA and UX!"

Resource More/Less

• Program: 50-50 split between just right/more
• Product: More is more. Though a small percentage thought it was just right
• Engineering: Majority thought we needed more resources and/or needed to make them more efficient
• QA: More is more; many thought the support was just right
• Release Management: Majority thought support was just right
• UX: 50-50 split
• l10n: 50-50 - largely depended upon point in project

Roundtable