I released new code yesterday and as usual stuff breaks. Something is always going to go wrong: broken features, change-averse users, unhandled edge cases… danger is everywhere.
A launch is not just one moment in time, it’s a cycle. And the more you go through the cycle, the harder it gets to overcome Launch Resistance - the fear of breaking stuff that used to work.
Move fast and break things. Developers hear it a lot, and yet, there is always a lingering fear that things won’t work out the way you want them to. They rarely do.
I broke a core feature of the website: the writing editor. You can whine and hide, or you can fix it. I chose the latter and released a fix in one day of work. Will it matter in six months? No, so why should I care now? I learned more in one day of breaking and fixing things than in one day of preparing things.
Breaking things is taboo in the engineering world. In school, we are told we need to handle all the use cases, to prepare for every possibility, that we need to be perfect. There is no such thing as perfection in this world, and if it does, it will kill your soul.
As a maker, you can’t afford to lose time. Never forget you work WITH users, not just FOR them. Throw stuff at them and they will tell you what they like and what they don’t. That’s how you fix and improve things at the same time.
What about Unit Testing then? It’s important indeed, but never forget you can’t prove the absence of bugs, so don’t spend too much time testing things programmatically. Confront yourself to reality.
Thanks to all my users for the support, and don’t hesitate to ping me if I can help you with anything.