Written 56 years ago, the Litany Against Fear plays an important part in the novel Dune, allowing the protagonist to overcome his crippling feelings and go through difficult ordeals. Recently it dawned on me that it could be just as effective - and just as true - when dealing with fear of change in software systems. Let's go over the litany line by line and consider its meaning and implications.
I must not fear change
Change is good. If your software doesn't change, it makes your life boring. It also means that your company / project is at a stand-still, which is never a good thing. In healthy software systems, change is the only permanent, and any part of the system is subject to change at any given time.
Fear of change is the mind-killer
When you're afraid to change your software, you often resort to solutions such as manual testing, installation on a staging environment, waiting with deployment to production until important company milestones pass, and so on. This is demoralizing and depressing, and when developers' day-to-day existence revolves around wading through quicksand, their effectiveness and mental health take a significant hit.
Fear of change is the little-death that brings total obliteration
Good developers leave companies where fear of change cannot be defeated. And your good developers are the only ones who have any chance at all at defeating fear of change. The mediocre developers who remain will resort to making quick-and-dirty fixes, slowly making your system into a big ball of mud and further diminishing your chances of ever breaking out of this vicious cycle.
I will face my fear of change
There is no other way. Any hope of redemption must begin in a decision not to succumb to the little death of quick fixes and putting out fires. Your ability to face your fear of change relies significantly on your confidence in your automated processes - tests, deployment, monitoring, alerting and rollback. Early investment in these areas is a proven enabler for successfully mitigating fear of change.
I will permit it to pass over me and through me
Facing your fear of change will require you to start making frequent changes to your software. You might say "but I'm afraid to make infrequent changes - how can I make frequent ones?", but the reality is that small, frequent changes are much simpler to deliver. If you make a small change, even without a comprehensive suite of tests, and deploy only that small change to production, all you need are decent, off-the-shelf monitoring solutions to measure the impact (be it positive or negative) that change had on your production environment. And of course, good, maintainable tests are the best enabler for applying small changes to your codebase.
And when it has gone past I will turn the inner eye to see its path
"Inner eye" being an (admittedly weak) allegory to your feedback cycle. Let's examine why most engineers are afraid of change: it's usually their inability to deterministically hedge the impact of said change. The causes for this inability could be insufficient (or non-existent) test coverage, unclean staging environments that do not prove that the same code will work as expected in production, and the time it usually takes for any change to reach production (in your case - is it seconds? minutes? hours? days? weeks?). Imagine pushing a change to git and seeing its impact in production within a minute; in such a case - will you still be afraid to affect this change?
Where the fear of change has gone there will be nothing.
Software engineers who regularly practice TDD within a continuously-delivered software development lifecycle somewhat resemble Zen Buddhists. They exhibit an equanimity that might seem unreal or even annoying to developers who live in a quick-and-dirty, putting-out-fires mindset. They approach each change to their software with a beginner's mind, without prejudice, without expectations and without fear. That blankness, that nothingness, is what enables you to defeat your fear of change. It's what allows you to push a change to production without seeing it run locally on your machine or in a staging environment. On Thursday (or Friday for you non-Israelis) afternoon. To a production system serving millions of users. And then go home and forget about software for the weekend.
Only I will remain
And remaining is what it's all about. Remain in business. Retain your best engineers. And leave enough mental resources for yourself, the 'I' who might also be a parent, sports fan, hobbyist or anything else beyond being a software engineer. Otherwise, what's the point of being?
nice, gave me some stuff to think about
Nice, TDD fan myself.
Guess you are impatiently waiting for the remake of Dune ?