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

  • SQL CURSOR Performance – SQL For ProgrammersSQL CURSOR Performance – SQL For Programmers Last week I showed how to use the SQL CURSOR to loop through records in a database.  In that article I mentioned that you want to avoid using the CURSOR if you can because it has performance p...
  • SQL For Programmers – Finding IN a ListSQL For Programmers – Finding IN a List In the last SQL post, we looked at looking for content that was LIKE other content.  While this has its uses, it is limited in its ability to find more than one pattern.  So what if we want to fin...
  • Watching Trends = Job SecurityWatching Trends = Job Security I’ve been programming for 21 years now.  Most of my career I’ve spent being on the bleeding edge.  This has helped when it came time to find work because I normally am one of the few p...
  • Copy And Paste And BugsCopy And Paste And Bugs We all do it.  I’m sure of it.  It’s too easy. I need code that looks almost like something else I wrote so I just copy and paste it over to the new code.  Done. But at what cost?...
  • The Evolution of a ProgrammerThe Evolution of a Programmer This is almost true.  I think the season'd programmer would actually get back to writing as little code as possible prior to being middle management.  But, it's still pretty funny. The Evolution...
  • Ryan Kohn

    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.