"Quick and Drrrrty" vs. "Doin it Right"

I've had some small wins this week. For those who are developers, you'll be able to relate. Those that aren't, well, you'll be able to relate too, just under different circumstances.

I'd been struggling all week getting something working for our site. Again, I'm using Rails, and while it's been a breath of fresh air compared to learning C back in college, I've still had my share of hurdles. See, I'm a perfectionist when it comes to my code. Sure, I can find a way to do something "quick and dirty", but I always like to write the best code possible. That way, if you never get a chance to go back and refactor (which often happens), it won't be the end of the world. So many people I know just code to get things out there. Then when it turns to shit, as it undoubtedly will, they spend too much time fixing what should have been done right the first time.

I'm aware that there are separate camps on this subject matter. And both have their advantages. For example, the "quick and dirty" method will get you out the door more quickly. Which has its advantages. So is there a compromise?

I realized this week that the answer to that question is "yes". I spent so much time trying to figure out the "rails" way to do what I was doing that I got bogged down in details. It just so happened to help me redesign our database so that the data and presentation layer fit more closely together. Which is one of the key components of Rails. But not being a pro left my presentation layer with too much code. I just couldn't figure out a better way to do this. So I left it... not feeling great about it.

But what I realized is that I now completely understand my data layer and am comfortable with its design. That part won't need to change. But now I can leave quick and dirty piece available for refactoring - which hopefully will happen. I've asked our other engineer to take a look when he gets time. I'm aware this might not happen... but it's more ok than an entirely dirty solution.

My point is that I think there can be a beneficial relationship between "quick and dirty" and "doin' it right the first time". Do right what needs to be right (the guts of the system, data, scaling, security, etc). And maybe, if you absolutely must, get that frontend component done quickly. Of course, there are exceptions. If an undue load is forced on your database because of your Q&D work....that's unacceptable. And if your system looks like shit... well, that's a problem too.