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

▲

bithive123 7 days ago | parent | next [-]

"The only way to go fast, is to go well." ― Robert C. Martin

▲

christophilus 7 days ago | parent | prev [-]

Software that goes fast changes human behavior. It seems you’re thinking it changes the software’s behavior. Not sure. Either that, or I don’t follow your comment at all.

	▲	devmor 7 days ago \| parent [-]
		I'm not really sure how to rephrase it, so I can try an example. Lets say that the author has a machine that is a self contained assembly line, it produces cans of soup. However, the machine has a problem - every few cans of soup, one can comes out sideways and breaks the machine temporarily, making them stop and unjam it. The author suggests to double the speed of the machine without solving that problem, giving them their soup cans twice as fast, requiring that they unjam it twice as often as well. I believe that (with situation exceptions) this is a bad approach, and I would address the problem causing the machine to get jammed before I doubled the speed of the machine That being said, this is a very simplistic view of the situation, in a real situation either of these solutions has a number of variables that may make it preferable over the other - my gripe with the piece is that the author suggests the "faster" approach is a good default that is "simple", "magical" and "fun". I believe it is shortsighted, causes compounding problems the more it is applied in sequence, and is only "magical" if you bury your head in the sand and tell yourself the problems are for someone else to figure out - which is exactly what the author handwaves away at the end, with a nebulous allusion to some future date when these tools that we should accept because they are fast will eventually be made good by some unknown person.