How to succed in coding optimized programs.

Most people cant be race-car drivers, yet they can drive a car. Same goes for programmers, most optimization of the code is today done by the compiler. So there is seldom any need to manually optimize loops or fiddle with the small things. This however does not excuse giving up optimization or making your program to work as snappy as possible. Here are a few steps, I will explain them after but these are good to copy paste into your word-document, print and put near your computer.

  1. Choose the correct algorithms for the problem you are solving.
  2. Write readable functional and documented code
  3. Test (on the hardware you are gonna run it on)
  4. Analyze the test’s and find the weak-spots.

Choose the correct algorithms for the problem you are solving.
This might seem obvious, but it’s not and it is the step you’re gonna correct most of the time. There are in normal software development to many variables to keep track on to choose the correct algorithm the first time. This does not mean you’re a bad developer. It’s just life.

Write readable functional and documented code.
In this step, don’t pre-optimize, don’t write hard to read code just because you can or want to show off how smart you are to the few other that could be reading the code you write. The longer it takes to understand the code you are writing, the longer it will take to fix bugs, and the slower bug fixes and new features will come to the user of your program. Now who do you really care about? think about it! Why document you ask? well, because if you write in plain English (or whatever your preferred tongue is) you explain what the code is supposed to do, if someone finds out that it doesn’t do as described the bug is probably there. Coders who say “all you have to do is read the code” has it all wrong. Think about it like a destination and driving instructions”. If you only get the instructions like this: “take a left, walk 2 houses, take a right ….” without the destination clear someone who knows the destination and how to read and write instructions wont be able to fully understand.

Test (on the hardware you are gonna run it on)
You probably have a decent to really fast computer. Do your users have that? do they need to? If you’re writing for a microprocessor or mobile-phone or similar. there is one thing I can tell you, DON’T TRUST EMULATORS. There is always small but crucial differences on running on your computer or on the actual device. It could be they way you’re holding it, the way it reads from file-system. What I’m telling you is that there is no substitute for testing it on the hardware the costumer is gonna use your program on. The sooner you test it on hardware the sooner you’re gonna find the things about your program that sucks, and you’re able to fix them. The sooner the better!

Analyze the test’s and find the weak-spots.
Did you choose the correct algorithm to solve your problem? is there a performance bottleneck somewhere that you didn’t thing of? Fix it.

Most importantly do this for every feature added. If your writing something for a platform other then the one you are writing code on, test on hardware as often and as soon as possible or you will fail.

This was a nice little Saturday morning rant. I should do this more often, I was actually angry while typing. And I borrowed a lot of the language from a book I’m going to review in a little while!

Leave a Reply