[Go Faster] shipping quality code faster

Chris Hofmann chofmann at mozilla.com
Tue Sep 29 15:50:19 UTC 2015


On Mon, Sep 28, 2015 at 2:12 PM, Robert Helmer <rhelmer at mozilla.com> wrote:

> I think we're getting
> bit off-topic for this thread though so I've changed the subject.
>
>
you are right. good move


> I would argue that anything that ships as "Firefox" needs to be
> reviewed and put through our standard security, QA and post-release
> processes (crash analysis, telemetry and so on). We should continue to
> invest in and improve these processes.
>
> One argument here is if the overall process *needs* to take 6 weeks
> from code landing in-tree to getting into user's hands, and (if so)
> are add-ons the right vehicle to deliver this.
>
>

> I am certainly not suggesting we skip things like QA, security
> evaluations and crash measurement. While we should be able to do
> things like ship features to a subset of users and get more real-time
> feedback on how things are going before rolling out further, we still
> do need to review and evaluate and test the product as a whole before
> we even begin the update process.
>
>
Right, these are exactly the things we should be exploring and dicussing
and sharing perspectives on.

The great thing about Mozilla is that we get lot of people coming from
different perspectives.  Sometimes that makes the sharing hard, but in the
end we've usually got to a better place as the result from looking at
problems from a lot of different angles.

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.  Think of these as the
the billboards on the highway.  If I'm building a billboard I definitely
want A/B testing, the abilly to morf or replace the whole presentation, or
parts of it, at a movements notice.  I need this to monetize the space and
make to productive and as way to serve my needs, and also to make it
interesting to those who view it. If I make a mistake I definitely want to
be able to erase or correct that mistake and that's probably ok.  People
will probably drive by again and I'll engage with them on there way down
the highway next time.  As a viewer of the billboard I have an
understanding that I can't control or influence its content or message.
I'm just a passive viewer and can either choose to view it or just look
away.

On the other side of the highway is the car.  Think of this as the
browser.  Its the user agent of the driver that allows complete control
over where and when they travel, how they get there, and in what style.
Its the comfortable place that provides the driver with a familiar, stable,
and reassuring experience.  If I get in someone else's car with slightly
different features or handling I'm always a bit nervous, feel out of sorts,
and in less control.    If someone tweeks the software under the hood of my
car to improve gas mileage or performance in someway without telling me I
get outraged.  Changing and updating things on me frustrates and annoys me
to no end.  I know that I need periodic maintenance (gas)  weekly, and
every few months I might need to lose the car for a day to get a tune up,
and every few years I'll need replacement.   Those are my expectations and
demands and what I put up with.  But the underlying thing is that I do
these things to maintain freedom and control over my ability to move around
and get to the places where I want to go fast, efficiently, and effectively.

At some point its worthwhile examining these analogies and confirming them
as models for how we think about the web and browsers.    Are we building a
billboard, or are we building a car, or are we building something
completely different?  Maybe it really is a hybrid, but lets have that
discussion?  If we are building something like the car we definitely would
have a different set of design principles and techniques than the billboard
and would think about the problem in largely different ways.  We might
barrow other techniques on occasion, but not without examination of if that
technique really meets the needs of the target user and their expectations.

Strangely the PRD still has no guidance on how users might be served by
system addons.
https://docs.google.com/document/d/1H0be9rVfK-molaEa3KPvPLO4hS6iSKs-eHy2HGQwMNY/edit?pli=1

Maybe that's a hard topic to abstract and approach since the project has
mostly been about trying to prop up some test infrastructure to see if the
concept might work; but to me there are certainly some land mines that
system addons and and more/faster updates should be avoiding in its core
design to not degrade the user experience we provide in the browser.   If
we can't do at least a little thinking and analysis on this topic and clear
a few hurdles we aren't going the right due diligence.

The land mines are all those things that are mentioned in the car analogy
above. Especially about that core issue of "what is the optimal update rate
of new features?"  To me its worthwhile exploring the simultaneous
flattening of market share and the shift to 6 weeks cycles from longer
cycles and bigger feature releases that attracted waves of new users.  We
are repairing this a bit with the momement in time releases, but are we
doing enough to align all parts of the project behind bigger bullets, or
are we setting up ways to further fragment our efforts?    Its questions
raised by mossop about if we really need restartless or not, or when we
might need it to have a successful feature that might be accepted, used,
and loved(?)  by users.  What have we learned from our restartless addons
work of the past.  How did it apply, or does it apply at all in this case.
Restartless addon's on amo help to streamline the process when users have
made a choice and picked an addon and want to get it running fast.
Restartless addons for systems addons might be viewed as a bit more
clandestine, since the download or a new feature is silent and the feature
with new button/UI might suddenly pop into view in the chrome, or something
even more subtle. Those kind of things violate all those user control
characteristics I mentioned in the car analogy.

That's all I'll say on this for now but I'd encourage people to think about
what we are doing in this way.  I'd be happy to discuss or take criticism
on how these ideas are flawed or not useful.

-chofmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150929/6d10b0e3/attachment.html>


More information about the Gofaster mailing list