If It Is Hard, How Can It Be Good?

In discussions about good development practices, there's sometimes an exchange that can be paraphrased as such:

A: Well, I tried XYZ and it didn't work.
B: You probably didn't do it right!
A: Well, if it's so hard to do it right, it can't be a good approach!

(Where XYZ can be your Agile methodology of choice, or any of Test-Driven Design, Trunk-Based Development, Continuous Integration, or any other practice from eXtreme Programming...)

I think that's a copout. Doing the front crawl with proper form is hard, but it's the best way to swim really fast. Playing the Sicilian Opening in chess is really, really hard, yet Grandmasters prefer it over easy to learn "system openings" in their serious games. And, yes, writing good user stories in an agile way is hard (way harder than just going through the motions) and it's a great way of having the all-important conversation between the product and engineering side of things.

Yes, we have to be mindful of the fallacy of inventing some utopian perfect way of doing something (in theory) that really doesn't work in practice. But practice being hard doesn't mean it's not the way. And, worth pointing out, hard doesn't mean complex. Often it's the opposite.

Top athletes know this, and we should take it to heart as well.