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 to paralyze me. These are some principles I use to help me make coding decisions.
1. Don’t rewrite your application. Ever.
This explains it better than I ever could.
2. DRY – Don’t repeat yourself
“Every piece of knowledge must have a single, unambiguous, 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 write 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/execute call every single place I need it. This works for one off calls, but if I need to get that more than once or twice, a function is a better choice. I won’t have to worry about making a mistake each time I write the code. This is a contrived, but relevant, example.
3. YAGNI – You Ain’t Gonna Need It
“Always implement things when you actually need them, never when you just foresee that you need them.”
Simply put, if you don’t need it today or tomorrow (soon), don’t write for it. Maybe put 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 support that bloat. If you need to refactor, you are refactoring more code. You have 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 might 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 when you aren’t even using the power of one? Why write some awesome abstraction when 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 creme de la creme design. Unfortunately, I found that I never actually wrote the application. I got stuck in the design and never built out all the features I needed.
In a time crunch, you need the code to work. It doesn’t matter if it’s fast or pretty, if it doesn’t work it’s worthless. Usually, I can make it fast enough with iteration one, but as a system grows you’ll need to make things faster. As each pain point in speed becomes apparent, whack it out. Eventually, you’ll discover where you need to optimize. Finally, making it pretty by identifying code duplication and eliminating it where needed.
These principles have helped me write better software. I hope they help you too.