This editorial was originally published on Nov 7, 2013. It is being rerun as Steve is on vacation.

I saw a great quote recently on an internal email at Red Gate. We had deployed a new feature to a website, the application seemed to be working, but someone questioned the architecture of the implementation. The person who was in charge of the project sent this back at the end of an explanation:

"It’s a little clunky, but we decided it was better to get it done than make it perfect."

That's a great quote. In fact, that's what I've aimed for in most of my career. Move things forward, get them done in an effective manner. That's what I've tried to do as long as I've been in technology. Examine a problem, consider various solutions, and then choose one to move forward with. At the end of the day, as has been said by many people, "shipping is a feature".

This doesn't mean giving up on quality or accepting anything, but it does mean that you continue to move forward. You may make compromises on code quality, but small compromises. Your code has to still solve the problem. Your database still has to handle the load. You still need quality work, but a solution you can get done quickly that performs 10% worse may be better than a faster solution that takes twice as long to develop.

Lots of code lives in systems for years. We want this code to be "good" in that it needs to work, handle the load, and contain few bugs. However lots of code also gets refactored over time. We should minimize bad code as much as possible, but less than perfect code isn't bad. Sometimes it's just a little clunky, but it gets the job done.