Quality Is Fractal
ramenapp.net
ramenapp.net
Yes, quality (often) has this one bad apple spoils the whole bunch property. If we have to have a math metaphor we might say that quality is multiplicative, in the sense that one low value in a sequence still impacts the entire product. Or we might say that quality has an absorbing element, by which we mean that any zero value kills the whole set (100 * 100 * 100 * 0 still equals 0). But fractal means that we see self-similarity at all levels. That hardly seems to be the case.
According to the original argument, bad software implies bad programmers which implies a bad company. That seems not only incorrect but also non-constructive. It ignores (e.g.) the idea that good employees could release bad products under bad management. Likewise, great programmers can write applications which are terrible to use. There are other skills involved in that process (interaction design, for instance). The criteria for evaluating programmers and software are vastly different and thus it doesn’t make sense to say that there’s a fractal relationship between these two vastly different kinds of entities.
I'd be happy to have 3 lines of subpar code if it gave me an advantage on other competitive angles.
Nevertheless, "quality" is an ill-defined concept, and it's easy to be led astray in pursuit of notional quality at the expense of real-world practical improvements to your product. For example, cost and ease of use are not independent factors. Consider VHS vs. BETAMAX video recording as a classic example. BETAMAX had superior recording fidelity, but it was significantly more expensive, and expense plus network effect was a major factor in the adoption of video tape standards.
Part of the "quality fractal" are meta-features such as robustness, elegance, usability, performance, and cost. It doesn't matter how theoretically perfect your product is if it's not practical or it's too expensive to serve the market effectively. A Bugatti Veyron may seem in many respects to be a "perfect" automobile, but it's not. The luxurious interior, amazing build quality, and high performance make it easy to overlook the downsides such as the extreme cost, low mileage, low lifetime of many components (such as the tires), high maintenance cost, etc. In most regards a Toyota Camry is a superior car to a Veyron. That's a result that it's very difficult to arrive at if you focus too myopically on the ideal of "quality" without looking at things holistically.
Compare, for example, consider the world-wide-web vs. project Xanadu, or Linux vs. Hurd. It's so easy to let perfect be the enemy of good. The concept of "worse is better" is on the surface a refutation of the importance of quality but in reality it's just a reminder that "quality" isn't always what we think it is and practicality is always by far the most important quality.
"Finished is better than perfect" is probably a better startup philosophy. I've seen too many friends waste time on the nth refactoring of their code rather than focusing on shipping and proving customer value.
I've seen too many products become a miserable mess because people believed in "finished is better than perfect". But that's something you learn when you're rewriting your code for the nth time to add the nth feature because otherwise you just can't fit anything new in there.
But as I always say on these occasions, please keep shipping bad code. I make good money fixing it.
You can still be fast and good, though it takes more discipline than just cranking out workable but crappy code.
Guess we mentioned fractals
This requires a lot of focus and mental energy, but it deeply rewarding in it's own right.
I will certainly be quoting the phrase "quality is fractal" - so will you soon:-)