
The Management Fix That Made Firefox Faster - prostoalex
https://www.wsj.com/articles/heres-how-firefox-workers-were-motivated-to-squash-bugs-1503399604
======
mattmanser
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?

~~~
michaelt
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.

~~~
mattmanser
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.

------
hutzlibu
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

------
dieterrams
Non-paywall link: [http://www.cetusnews.com/life/The-Management-Fix-That-
Made-F...](http://www.cetusnews.com/life/The-Management-Fix-That-Made-Firefox-
Faster.BJ31CCJvoFOW.html)

------
warcode
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
Yet another pay-walled posting on HN...

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

