Programming Languages

My oldest son is back in college and currently working on a really long programming assignment. The course requires him to use the Java programming language and he is not very happy about it. At the beginning of the project, he was told by the teaching assistants that his code would approach 5,000 lines of code and take 3 weeks to write. Part of the reason for the class is to show the flexibility of Java. My son doesn't see it that way. His preference would have been to use Erlang. He could do everything the 5,000-line Java program does with 25 to 30 lines in Erlang.

This brings up the topic of programming languages. Not all of them are created equal. If you want to write something that runs very fast and only needs to run on one platform, do it in Assembly. If you need something to run as fast as possible but it may run on a number of different operating system (i.e. Linux, Windows, or Mac), then use C. If you are working with statistics then R is your best choice. A good software developer will know the benefits of a number of different languages and apply the best one for the problem at hand.

Does that mean that every software developer should know every language out there? No, but he or she should be familiar with a number of different languages along with the strengths and weaknesses of each. Software developers should also be experimenting with new languages when time permits and not rely on one language to do everything. After all, 30 lines in one language is a whole lot less work than 5,000 even if you have to learn a new language. The 30 lines of code is also a lot easier to maintain.

Proper Software Development

I am working on several software development projects. Some for work and others for my own personal edification. One of my projects has recently come under some deadlines and so I have been forced to take one or two short cuts. This generally means that proper software development methods get thrown out the window in favor of getting something done quickly. You might be able to get away with it for a day or two, but eventually it will come back to bite you.

Having been in the software business for the past 26 years, I have learned when it is best to avoid certain short-cuts. This saved me today. Even though I was told to move a piece of code into production, I did so long enough to run a single test. Then I backed out the new code and put the old working code in place until the results of my test could be properly verified.

The new piece of code seems to be working correctly. To me, it works exactly the way I wrote it and the way the user asked for it. However, sometimes those looking at the results don't like what they asked for and request more changes. If I had left the new code in place, it would have meant a lot more work should any changes be requested. Guess what? There are always more changes and I saved myself quite a few hours of work.