Keeping it Simple

In my second year of NAIT one of our instructors decided that we should enter a programming competition put on by ACM.  With more than just a little curiosity we entered the competition.  One of the problems was to print out a multiplication grid, using Roman numerals.  We had a difficult time with this question, but when we finished we had a program that could print a grid of almost any size and convert the numbers into Roman numerals.  It worked, but our instructor was disappointed.  He asked us why we made it so complicated.  All that was asked was to print out the multiplication grid, so why hadn't we just printed the grid with 12 PRINT statements?

Talk about keeping it simple!!!

Blaire Pascal, a French mathematician and philosopher, once wrote "If I had more time, I would have written a shorter letter."  This completely goes against "traditional" productivity measurements in IT that state each programmer should generate x KLOC (thousand lines of code) per month:  if you generate more, you are more productive.  Generating more lines of code goes completely against keeping it simple.  The odds are you are cutting and pasting lots of code, doing things in ten lines when it can be done in one and generally doing your best to add fluff to the application.

The next time you are sitting down and writing a method in the language of your choice, check to see the size of the method.  A mentor a number of years ago had a simple rule:  if you can't see all of the lines of the method on the screen at once, rewrite it.  I have tried to follow this as closely as possible for much of my professional career and have been quite successful.  By, quite frankly, putting in arbitrary limits I have forced myself to think simple.  Sometimes a single method needs to be greater than the height of the screen, but this is an infrequent occurrence.

Keep it simple and you'll be surprised at how productive you really are!