Quality Means The Flexibility to Change

Here’s Ben Nadal quoting Dave Farley:

I've come to the belief that the only definition of quality in code that makes any sense is our ability to change the code. If it's easy to change, it's high quality; if it's hard to change, it's not.

Then Ben comments:

I'm sure that some people will have the reaction that such an outlook is nothing more than an excuse for not doing things the "right way". But, I think that's exactly what I love about this insight—that it separates out the academia of software development from the pragmatic realities of the world. Sometimes, the sub-optimal way is actually the way that makes the code easiest to work with.

Love it.

The thing about software — and life really — is that whatever you’re doing, you’re undoubtedly doing it wrong. You’re human. You make mistakes. You’re not perfect.

If you’ve been practicing whatever you’re doing for a long time, you’re probably making fewer mistakes. But you’re still making ’em.

For me, this is true of basically everything I’ve tried in my life, from cooking to sports to software.

When I start, I’m usually wrong in very profound ways. The cookies melt to discs when baking. My golf shot is a complete shank. My code is total spaghetti.

But those results (hopefully) teach me something, so the next time I cook, or swing a club, or write some code, I approach things differently.

Given that I’m always going to make mistakes, it is of vital importance that I construct short, inexpensive feedback loops to facilitate the plethora of changes and adjustments I’ll need to make.

• Cooking: Don’t buy 20 pounds of wheat flour only to learn I should be using white flour.
• Golf: Don’t buy low irons when my swing is more well-suited to playing hybrids.
• Code: Don’t npm i yourself into a dependency hole you can’t dig yourself out of.

Whatever you do, make it easy to change. As easy as hitting CMD+Z to undo your last action on the computer — if only life had a similar undo button #amirite?