Is efficient code obsolete?

I was looking over some of my older code noting how inefficient some of my code was. There were a number of reasons for this. The biggest is my very short development time. In my case, the short schedules are the result of my desire to release a lot of material. I have tried to slow down my release schedule to allow for better content, but other things always seem to creep in to steal my spare time. Unrealistic schedules are far too common in the tech industry and is made worse by the fact that the vast majority of people in charge have no clue how software works or how much work is involved in its creation. Making this problem worse are the programmers themselves who often vastly under-estimate the work required to complete a project. Short development time leads to focusing on just getting the code to work not on getting the code to work as efficiently as possible.

Related to the short development time is the fact that often I will cut and paste similar code from earlier projects that I have worked on. I restrict myself to code that I have written, though there are many programmers who will cut and paste from other peoples' code.  By tweaking existing code, you can implement something very quickly. The problem is that often the code you are borrowing may have stuff in it that you are not using within the new project but that was necessary in the original project. The fact that you are cutting and pasting code probably means you are in a hurry which means that the redundant and unnecessary code that is copied will remain resulting in both code bloat and inefficient code. Changing project specifications in the middle of a project, which is sadly far to common, also results in unnecessary code bloat for similar reasons.

A third common reason for my inefficient code is that the code in question is not going to be executed very often. This is related to the first reason due to the obvious fact that functions that are infrequently used are going to be written fairly quickly. Another reason that infrequently executed code tends to be inefficient is that there is very little incentive to optimize the code as the inefficiency of rarely executed code is not going to noticeably impact the overall speed of the program. Optimising a program takes time so that effort should be placed on the parts of a program that are executed frequently or that are most critical to the speed of a program.

Not all of my reasons are related to development time. I often will write code that I can easily understand instead of using more efficient code that was harder to grok. For example:

    c = Math.min(a,b);


This code obviously sets c to be the lower of the values a or b. It is, however, making a function call which has overhead and if the function call uses floating point while the variables used are integer you have a number of type conversions as well. Many languages have generics and will inline small code blocks right into the code if compiler optimisation is enabled which can mitigate the speed difference. In the best case, the compiler would essentially convert the function call into the following statement:

    c = (a < b) ? a : b;

If you were to use the second version of the code instead of the first, you would be guaranteed no function call or type conversion overhead. I find first version much easier to understand, but depending on your compiler it could be substantially slower than the second version. The difference is in the millionth of a second, though.

None of this even gets into the facts that the code being written is often going to be interpreted or ran on a virtual machine. Likewise, the speed of computers is not looked at. Worst of all, the fact that programmers are no longer familiar with low level programming so write code that doesn't compile efficiently is not addressed. Those are topics for another column or three. Still, the conclusion that I have come up with is the simple one that computer time is far cheaper than programmer time which is cheaper than time-to-market time so it is safe to say that while writing efficient code is still something to be aimed for, getting code out quickly is sadly the bigger priority.

History Bombs a couple days early

It has been a while. My plans were to continue posting every week or so, but things are busy here so I kind of kept forgetting. Things may continue to stay busy based on how well a proposal I am working on goes but I will try my best to post at least a short article every other week if not every week. To make up for my delay, here is a sneak preview of February's game. http://blazinggames.com/table/dozenDays/words/historyBomb.php.

Santa vs the Evil Gnomes 1.0 release

At last my Christmas game is finished. Sure, I would have liked to do a few more passes but as always time is the enemy. I think the game is pretty good but I am biased. I have been thinking a lot about what I am going to do in 2010 and the best words to describe my plans are icing. I will be posting my plans for all 9 projects that make up the Blazing Games site on New Years Day. There are some big changes that are going to be happening which will hopefully turn out to be positive and result in BlazingGames.com being a much better site.

Plans altered

I was originally planning on releasing the final version of Santa vs the Evil Gnomes this week and releasing the Christmas Edition of Dungeon Romp 3D for Christmas but with the passing-away of my Grandmother and lack of time due to family being down my plans are being altered. While I am very tempted to delay Santa vs the Evil Gnomes until next year and add a lot more features, I have delayed the game enough as it is so it will be Dungeon Romp 3D Christmas Edition that gets delayed and Santa being released on Christmas Eve.

Santa vs the Evil Gnomes beta release

I was going to have the first two maps of the Santa vs the Evil Gnomes game, but as there is no save feature so players would have to replay the whole thing so I just left the first level in there. The full game, which I hope to finish this weekend, will have 3 maps. The story is not as good as I hoped due to time limitations and what could be done with the rpg/3D engine that I am using. That is why I was glad that most people who answered my poll voted for a longer release between games as that will allow me to make better games. I am also planning on enhancing some of my older games so if there is a particular game you like that you think deserves some enhancements email me (webmaster at blazinggames dot com works). There was only one vote for never updating the site. In the unlikely event that the person who made that vote is reading this, I would love to hear your reasoning.

A Cold Poll

My plans for this weeks site release were derailed when I came down with a cold. I usually don't get sick, at least not this bad, but I have been dieting which is probably not helping my immune system. I still have a lot of weight to lose, but I have made great progress this year. Still, my planned release for this week is not as far along as I would like so I am having a poll instead. After all, 2010 is closing in fast and I have to make my 2010 site plans so why not get a little help from people who actually visit Blazing Games?

Wasn't Halloween a month ago?

Vampire Attack release 1.01 was posted with a strategy guide. The big feature that was added was a scoring system. I was also going to add more sound effects, but figured that there are some sounds that are going to have to be changed when I release the game as open source next year so I will just wait for the open source version to add more sound.