This past _why day an email made the rounds that _why had sent two years prior to someone asking how they could become a better programmer.

The crux of the email was: if you follow the rules you are not going to maximize your risk and your creativity will suffer. Programming, for him, was about experimentation and discovery versus adhering to rules to produce objectively good code. He didn’t write tests. He didn’t follow any particular style or convention. He did some pretty amazing things. (And then he disappeared.)

The entity/story/folk hero that was _why is one of my favorite subjects to talk about when I’m drunk and talking about Ruby or Rails. If you haven’t read about _why you really should start with his Wikipedia page and definitely his book: Why’s (Poignant) Guide to Ruby. (I’m a fan of _why, can you tell?)

BUT…here at Simpleform one of our (and I will use this word even though my Catholic mother would give me a dirty look for using it that way) religions is testing. The other is shipping. We love shipping. Shipping is what makes your day worth it and if I leave my office having not shipped anything I mope.

The shipping is the fun part, the work is the testing. Testing builds trust amongst our team and with our clients. Without testing we’re potentially handing our clients a time-bomb, and worse, we’re charging for it. I hate this feeling.

So we test because we want to ship. And we ship because we want to make our clients happy. And if we can’t ship then nobody is happy. So we adhere to a set of standards and styles guides on how to test and how to organize our code.

There’s this line religious people use when they encounter atheists: “Without religion, where do you get your morals from?” Which is hilarious because I responded the other day to someone, “Without tests, where do you get your confidence in the code from?” and then realized what I was sounding like and laughed and laughed—but really I don’t get where the confidence comes from.

I used to think I was good enough to write code without tests. And to be honest, I never experienced a problem so major that data was lost or leaked. At FM every engineer was responsible for their own code and that plan mostly worked. Nothing catastrophic ever happened. But in the back of my mind there was always a worry that it might. It would only be a matter of time before something bad happened and I always felt a little nervous when I’d hear something wasn’t working correctly.

Even worse, changing a critical part of the application was always an arduous task of user testing and re-testing. It wasted time. It created a lot of worry and even when it was done I’d never feel great about it. Automated testing means you can make those changes and feel great when you ship.