Home » none » Coding Priorities

Coding Priorities

land-056

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.

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • 15 Ways To Write Beautiful Code [That Have Nothing To Do With Testing]15 Ways To Write Beautiful Code [That Have Nothing To Do With Testing] I got a question this last week that I answered very briefly but I felt that to answer it completely would take a blog post.  So here’s the blog post. Should the author of a piece of […]
  • JavaScript Performance TweaksJavaScript Performance Tweaks So, I started reading High Performance JavaScript recently and I thought now might be a good time to give a summary of what I've learned so far.Up until recently, I wasn’t all that […]
  • 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 […]
  • ASP.NET Server Performance TestingASP.NET Server Performance Testing loading... This happened a couple of years ago, but it is still relevant because I know of at least one place where it is still happening even though Microsoft has fixed the issue […]
  • 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 […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.

  • http://ryan.kohn.ca/articles 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.