> Rarely in software does anyone ask for “fast.”

> But software that's fast changes behavior.

I wonder if the author stopped to consider why these opposing points make sense, instead of ignoring one to justify the other.

My opinion is that "fast" only becomes a boon when features are robust and reliable. If you prioritize going twice as "fast" over rooting out the problems, you get problems at twice the rate too.