The Balance Between Safety and Speed; or, Does the Turtle Really Beat the Rabbit?

Eric and I argue about programming all the time and about every little thing, but we're really just arguing about one thing. I value safety, and he values speed. Let me elaborate.

The safety I'm talking about is making sure my code works right. I'm for strong typing because it can help find errors at compile time. I believe that databases have to enforce their constraints as best they can even if you're the only client. I prefer centralized version control (CVCS) over distributed version control (DVCS) because the restrictions CVCS enforces promote healthy branching and code. I believe in continuous integration, including full unit and integration tests.

The speed Eric talks about is being able to write "5.times.per.day" in Ruby and have it just work the way you expect. Eric loves git because he's able to get input seamlessly from developers around the world and easily integrate new code. And he loves easily discoverable features of his languages of choice.

Most of the time, the programming context determines the value of the two assets. Building a mission-critical app that handles financial data? Safety rules the day. Building a site to determine if it is Christmas or not? Speed please.

Programmer personality also is a significant factor. I know I make mistakes, so I prefer to use tools that prevent/detect said mistakes. I also know that others might use my code at some point, and as anyone who has ever worked with someone else knows, other people are dumb.

The reason I just started writing about this was because I had to change a "Thread.Sleep" call in one of my integration tests from 2 seconds to 5 seconds. To make this change and formally deploy the code to my project's development environment, I had to run the code through the entire 12 minute build process. And that's AFTER running the unit tests locally (5 more minutes). It would've been so nice to circumvent the whole process. And I wanted so much to do just that! But I held fast to my rules, and now I know the published package built from that build is ready to be released to QA.