The optimization rule for systems

July 1, 2007

One of the rules of optimizing program performance is that there is no point in optimizing code that is not run very often; you optimize the performance critical code, and then move on to other work. There is a similar principle in system design and system administration: improving an area that is not a concern to people does not really excite them. To significantly improve people's lives, you have to work on something that they care about, something that is hurting them now.

An important consequence of people not caring is that they aren't willing to put up with pain to get your improvement. Since your improvement has to make their lives better (or at least no worse), dealing with your improvement has to be less of a pain than what they're feeling now.

(In fact, this crops up all over in various forms.)

One problem that bedevils boosters of new technologies is that they over-estimate the degree of pain people are feeling from the area that they're improving. Put crudely, they're so close to their area that they wind up thinking that everyone cares about it as much as they do. (A common side effect is for such people to also underestimate how much of a pain their new technology is in practice.)

Note that sysadmins are as much at risk of this as boosters of new technology; when we create bright shining solutions to some issue, it's always important to find out if the users actually care about it. Similarly, finding out what things are pains for the users is the first step in figuring out what's important to work on.

Written on 01 July 2007.
« Weekly spam summary on June 30th, 2007
What the unified buffer cache is unifying »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jul 1 23:32:25 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.