The Management Fix That Made Firefox Faster

https://www.wsj.com/articles/heres-how-firefox-workers-were-motivated-to-squash-bugs-1503399604

by prostoalex • 9 years ago

26 12 9 years ago

wsj.com

dieterrams• 9 years ago

Non-paywall link: http://www.cetusnews.com/life/The-Management-Fix-That-Made-F...

hutzlibu• 9 years ago

So the management "fix" is, "hey everybody, let's focus on bugs, that make us slower compared to chrome!"

... I expected a bit more, to be honest

mattmanser2• 9 years ago

I'd be surprised if this is true.

I suspect the truth is programmers were not allowed to focus on speed by management and now those same people are claiming their "fix" is what changed the programmer focus, rather than admitting their own short-sightedness and poor product management.

I love fixing performance issues, finding the refactoring and satisfaction from doing it very rewarding. I assume there are plenty of other programmers that do too.

But it's expensive work which doesn't deliver any functionality and can break things.

I'd be interested to know if you (as a programmer) think I'm wrong. Do other programmers actually hate fixing performance problems?

_Codemonkeyism• 9 years ago

The majority of developers I've met as a manager love to spend time on technical topics and performance compared to feature development - especially boring hygiene features.

Standard FF footer: I want vertical tab groups back.

jcelerier• 9 years ago

long live tree style tabs

vitus• 9 years ago

Well, I don't hate fixing performance problems, but I do see the value in deprioritizing them (... indefinitely, sometimes) if they don't render the program unusable by the end users, for precisely the reason you mentioned ("it's expensive work which doesn't deliver any functionality and can break things"). It's especially exacerbated if you know the way forward would probably take a week (or month, or more) of development effort, and for what? An incremental 10% improvement in load times?

When management shifts these priorities, it's not just at the scale of the individual programmer, it's company-wide. Suddenly it's a lot more justifiable to spin up projects for larger-scale performance fixes. Otherwise, you mostly have scattered individual efforts to clean up low-hanging fruit.

Regarding breaking things specifically -- that's one of the clear wins I've found with testing. Something breaks, so you write a test to (a) verify your fix and (b) ensure that you don't break that same thing in the future. Sure, there's extra upfront cost to writing good tests, but that saves you (or your coworkers) debugging effort down the line.

(disclaimer: I work at Google but am not on the Chrome team. These opinions are my own, etc etc.)

michaelt• 9 years ago

There are two types of performance problems.

The first type is where performance drops 40% from one commit/merge/feature/bug fix.

The second type is where performance drops 0.1% a time over 400 commits/merges/features/bug fix.

For the first type, the person who caused the performance drop can just be told to fix it; the solution will almost certainly be a change to code they own. The incentives basically line up. No complex management required!

But for the second type? Nobody would reject a fix for a buffer overflow because bounds checking slowed the code down a little. Fixing such problems might need hundreds of optimisations in different places - or offsetting slowdowns in some areas with speedups in others. Coordinating this sort of thing is what management is supposed to be there for.

mattmanser2• 9 years ago

There are a lot more types than that in my experience (I've added examples at the end), but perhaps we work in different fields. I don't work on windows apps like FF, I work on web apps.

Also, it can happen over a bunch of commits and not be one person's fault. An example might be a terribly performing DB query written by Barry but it's only used in an admin interface used once a year, then Sarah checks in a change 2 years later than happens to use the functionality regularly, but it's used every day, by every user.

Additionally, Web apps are very different in a lot of ways as you have one app serving 10, then 100, then 1,000, then 10,000, etc. etc. The performance problems appear from nowhere.

Another example of people deferring performance problems was a system I worked with that processed data, it was non-time critical and poorly written, but was fine when the company had 20 clients as they'd just set it and forget it, that was perfectly acceptable, it wasn't worth fixing. When they got to 100 clients 3 years later, they literally ran out of time in the day.

This is a regular cause of performance problems, terribly written SQL for reports that 5 years ago ran in 10 seconds, annoying but acceptable, but are now taking 2 hours to run.

Here are some examples of other types performance problems:

Problems of scale. The problem only appears when you have X number of orders or on-screen widgets, or when there are more than 200,000 users or whatever. Big O problems. This can be missed because your local db has 1,000 orders and your live one has 1,000,000 (which is a problem in itself, but one I have seen almost everywhere I've worked).

Race conditions. Everything's fine in a test environment, processing 20 orders a minute. When minutes turn into seconds, race conditions occur.

Strange configuration interactions. Problem only appears when you have feature X turned on, with feature Y disabled and feature Z set to option A.

Latency. When the DB/App latency is 0.1ms, the app is good, when it's 3ms, certain pages take >500ms because of hundreds of DB calls.

Bad Indexes/Query Plans/etc/. Problem only appears after your indexes gradually fragment or because the query plan was built when there were 20 things in the DB, and now there are 20 million.

warcode• 9 years ago

Speed is the feature that makes me go back to chrome every single time I give Firefox another chance.

I hope they one day fix the issues with performance degradation related to profiles. I should not have to reset everything twice a month to keep the same responsiveness.

m0d0nne11• 9 years ago

Yet another pay-walled posting on HN...

robin_reala• 9 years ago

To copy from the FAQ:

Are paywalls ok?

It's ok to post stories from sites with paywalls that have workarounds.

In comments, it's ok to ask how to read an article and to help other users do so. But please don't post complaints about paywalls. Those are off topic.

gcp• 9 years ago

The article lacks any content, so in this case that's feature.

The Management Fix That Made Firefox Faster

Related Stories