Software design is about iteration, not perfection

Over the years, I've learned some fundamental things about software development.
Writing perfect code with a perfect design is a fools errand. Perfection used t
o paralyze me. These are some principles I use to help me make coding decisions.

1. Don't rewrite your application. Ever. http://www.joelonsoftware.com/articles/

fog0000000069.html
This explains it better than I ever could.
2. DRY - Don't repeat yourself
The DRY principle is stated as "Every piece of knowledge must have a single, una
mbiguous, authoritative representation within a system."
While it can apply to data sources as well, I am applying this to code itself.
Every single line of code you write is a potential bug. You should strive to wri
te the least amount of code possible so you can depend on "known working" code.
If I need to get a record from the database, I can either write the select/execu
te call every single place I need it. This works for one off calls, but if I nee
d to get that more than once or twice, a function is a better choice. I won't ha
ve to worry about making a mistake each time I write the code. This is a contriv
ed, but relevant, example.
3. YAGNI - You Ain't Gonna Need It
"Always implement things when you actually need them, never when you just forese
e that you need them."
Simply put, if you don't need it today or tomorrow, don't write for it. Maybe pu
t a little underlying support code in, but don't implement it until you have to.
It takes time to add code, debug it and document it, time that might be better
spent on more pressing features. If you add the feature too early, you need to s
upport that bloat. If you need to refactor, you are refactoring more code. You h
ave to make sure it doesn't break.
After all that effort, you might even find that you don't need the feature (ever
), or you need something slightly different. The way you implemented it might be
mutually exclusive with what you actually need. Adding it before it is needed m
ight actually make you unable to implement a feature you need, or may lead to an
incomplete implementation.
A good example is scaling. Why would you write software to scale your servers wh
en you aren't even using the power of one? Why write some awesome abstraction wh
en it's not going to be used by anything?
4. Three simple steps:
Make it work
Make it fast
Make it pretty
I used to worry about the perfect application. I wanted everything to be the cre
me de la creme design. Unfortunately, I found that I never actually wrote the ap
plication. I got stuck in the design and never built out all the features I need
ed.
In a time crunch, you need the code to work. It doesn't matter if it's fast or p
retty, if it doesn't work it's worthless. Usually, I can make it fast enough wit
h iteration one, but as a system grows you'll need to make things faster. As eac
h pain point in speed becomes apparent, whack it out. Eventually, you'll discove
r