[Go Faster] shipping quality code faster

Chris Hofmann chofmann at mozilla.com
Tue Sep 29 18:20:43 UTC 2015

On Tue, Sep 29, 2015 at 9:10 AM, Laura Thomson <lthomson at mozilla.com> wrote:

> On Tue, Sep 29, 2015 at 11:50 AM, Chris Hofmann <chofmann at mozilla.com>
> wrote:
> >
> >
> >
> > Laura also shared there on the other thread
> >
> >> There's plenty of evidence that this is virtue enough to push ahead.
> >> Shorter cycle times lead to better quality and better agility to
> >> respond to user feedback. There are tons and tons of case studies,
> >> because so many companies have moved this way. We are dinosaurs in
> >> this industry.
> >
> > At first it struck me as odd and a bit offensive that she we use the
> analogy
> > of dinosaurs,
> >
> > That seemed to me to be unproductive.  Dinosaurs are extinct.  We have
> over
> > 100 million people using our software every day.  We can't be extinct.
> > Dinosaurs had no control over the destiny and were wiped out by external
> > events.   I'd like to think we still have quite a bit of control over
> what
> > we are doing.
> >
> > Then I did some more thinking about what she said and found something
> > underlying and a topic that might be good to surface as one of these
> > perspective differences that might be getting in the way of productive
> idea
> > sharing.
> >
> > Here is another analogy.  Its that we are building stuff for the highway
> and
> > that highway is the internet/web. I think we can all agree on that.
> >
> > I think the studies and evidence that laura's talking about and
> background
> > that she's coming from is from building web sites.
> <snip>
> Two things here:
> 1. Have you seen our MAU curves for the last few years?

Yes.  You have to know that I'm concerned about that from my posts here and

We are rapidly
> sliding into irrelevance.

  I'm not sure about the irrelevance part, but I think we can all agree
that growth had stagnated since 4.0 was released and that happened to
coincide with the change to 6 weeks release cycles and lack of big feature
based releases.

> We can keep denying that, but it
> accomplishes precisely nothing.

Not sure there is anything in what I've said the denies any of this.  On
the contrary its an honest attempt to promote discussion on what we should
do and where the best places to spend our efforts are.

That starts with a close examination and agreement of the problems we think
we face.

> If we keep doing what we've always
> done, we're going to go extinct, just like the dinosaurs.
Right, got it now.  Where is it that I've said we should just keep doing
what we are doing?

> 2. I have been here for eight years and I am profoundly sick of this
> "You're just a web dev" attitude I have been hearing for those eight
> years. Guess what? Web devs are some of our biggest customers and
> evangelists. Treating them as idiots is part of what has gotten us to
> where we are now.
Its clear I've touched a nerve here, and for that I'm very sorry.  I
apologize to you and anyone else that read my post in this way for anything
inferred directly or indirectly that I think the opinions of web devs are
not valuable or worth considering or acting on.

I made some analogies that building parts of the web infrastructure are
different and meant to serve different needs and audiences in different
ways.  You can agree with that, or as it seems you can discard it.  The
attempt there was to grow common understanding of things that have been
core to building browsers and things that are connected to the mozilla
mission parts that talk about acting as an agent for the user and placing
control, and how that might differ from building websites and services.

I hope you can understand the intent.

> In addition, if you paid attention to any of the presentations I have
> made on this, or on what's going on around you in Silicon Valley or
> the rest of the tech industry you'd know I am NOT just talking about
> websites. Yes, continuous delivery/rapid shipping started with
> websites, but I have pointed out many examples of client software that
> ships this way: Netflix, Spotify, Steam, and many, many of the iOS and
> Android apps that are killing the web ship fast and ship often.

Looking at user number for these it seems most would gladdly change for our
user numbers.

Netflix: 60 million total subscribers, 66% in the US
little but growing international presence compared to where we are.

Spotify: 60million total and 20 million paying customers
I don't recall exact number but we might be approaching that 20million
with donations from the single end of year campaign.  Certainly donations
are on the rise as we get better at excution and messaging around that,
and its a good sign of connectedness to our users.

Steam: 10 million concurrent users, 125 MAUs? and 75% pct of the games sold
Would growth be expected continue with that saturation into the gaming
Compared to our 100M+ ADU

Yes, its worth looking at what they are doing, and comparing to the types
of problems we face.

Will these client software providers face some of the same challenges we
face when they reach the scale and user base needs that we we have achieved
and are operating at?

Will they still do, or want to do, daily updates to there entire user base
when they reach into the broader set of users like we have?  Or will the
pace and need of update slowdown as their software matures and the update
cost increases as the result of incompatibilities and other problems they
introduce.  Certainly they all need update systems to refresh content as
that's the source of their business model.

I don't know the answer to their current or future problems.  I guess it it
would be good to learn and question.  I guess the first thing to ask would
be if any of these other orgs observe update fatigue or if they've found
some way to skirt the issues.  In growing products not so much time is
spent on analyzing the loss of users since the blast of the incoming funnel
of new users and the opportunies around those are so much greater.   At
least that is our experience going back to the early days of Firefox.

I do know that we have a defined problem of update fatigue and a bit of
data to support the loss of users as the result of frustrations around
updates.  I do know that what gofaster currently proposes is to ship
features and bug fixes faster and will run up against the update fatigue
problems that we've observed.  I see a collision here, but no discussion on
the options for avoiding it or addressing it. I've tried to start that

I've made a proposal to dig deeper into understand where the balance of
update fatigue sets in and how much of a role that's played in losing users
or stagnating overall growth as part of understanding that issue.  That
would infor us about how often we might realistically use out of regular
cycle system addon updates.  All those things seem valuable to me.  I'm not
sure if you agree or disagree.

> have been lucky enough to get insight from the three companies I named
> since Socorro is the leading open source app for client error
> reporting, and they all use it.) There are even embedded software
> companies that ship as often as possible, if not daily then weekly. (I
> have examples but would need to ask permission to publicly share them.
> They include utility companies, for example.)
> I've explained this over and over again, and I no longer have time to
> do so, so I'm going to go back to building the future of Mozilla.
ok,  sorry for creating your frustration.  that is definitely not my
intention, and I hope you understand and believe that.


> Respectfully,

me too.

> Laura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150929/d3fdb94c/attachment-0001.html>

More information about the Gofaster mailing list