Coding Priorities


When I was a younger programmer (I refuse to  call myself an “old” programmer quite yet) I made a lot of mistakes.  Chief among them was focusing on the wrong things at the wrong time.

Now that I’m older (and wiser?) I’ve created a short priority list that I find helpful as I write a new routine or system.

The first rule of programming is “Only code what is needed today.”  This sounds simple, but how many of us have written a routine or an entire system that had code in it to support a feature we were planning to add only to never end up coding that new feature?  Sure, that supporting code only took 5 minutes but

  • Lots of little 5 minutes end up taking a day or a week
  • Lots of extra code introduces the potential for lots of extra bugs.

There is one common sense rule that I apply here that some may see as counter to what I just wrote.  That is, “If the customer says there is going to be more than 1 of something, there WILL be at least one more than that in the future.”

That is, don’t hard-code multiples.  Make it so your code can handle as many items in the list as are ever presented.  If you do this up front, it won’t take any more time to write and it will definitely save you time in the future.

My next set of rules deal with optimization priorities:

  • Get it working
  • Get it working right
  • Get it working fast

That is, our first priority as programmers is to get something up that mostly does what it is supposed to.  It is understood at this point that there will be bugs, but we need a skeleton of the application first.

Once we have something that does most of what it should, we can then fill in the holes that we missed on the first pass.  This is the bug-fixing stage.  If it isn’t working as fast as we like, this is not a bug.  Do NOT fix that now.  This is  the functional bug-fixing stage.  “Given fast enough hardware, does this application do everything it should?”

Finally, we  can work on performance enhancements.

The reason we wait until the end of the development cycle to work on performance is that we will not even know if a particular block of code needs to be optimized until all of the code is written and we can find out where the slow spots are.  I find that most of us optimize code that only runs once every hour and completely miss the code that runs a thousand times a second.  Obviously the second is where any performance problems should be addressed.

Related Post

One Response to “Coding Priorities”

  • One more reason to not add in that extra supporting code is that irrelevant code can confuse or aggravate a future maintenance programmer, leading to a lengthier enhancement time, which is precisely what the original programmer had intended to avoid.