My first encounter with programming was around 1992 when I developed my first website. The website was complete with frames, flashing gifs and marquee tags. It was an absolute nightmare! Anyway, I gradually learned enough about computers and coding that I suckered a small company into giving me an internship. Although, I was hired to fix computers and maintain the test lab, I secretly always wanted to write code. Eventually, I convinced my boss to let me take home the Delphi 4 CD and a few months later I was hired full time as a software engineer.
Between my first hello world program and now, many things have changed. Programming languages have come and gone. We went from waterfall to agile and from extreme programming to test driven design. Nonetheless there are certain ideas and principals around computer programming that never seem to change. That is really the whole idea behind this post.
Never write code with the intention that you will fix it later - Chances are you will never have the time or opportunity to fix it later. Once code rolls into production, the maintenance windows become scarce. Like my Dad always said "Do it right, or don't do it at all".
Think large write small - When we develop new applications we generally start out with a few users and a little bit of data. For example, your application may start out with a thousand records but two years from now you may have 2 billion records. So think twice about queries that do a "select *" or methods that read in large datasets. Write your code with the anticipation that you will eventually have many users and lots of data.
Be "green" with your data - In general, I try to "Lazy Load" data whenever possible. There is no sense loading data that you may never use. My theory is load late and drop early.
Caching is also very important, especially with static information like lookup lists. For web development this could mean that you store some data in the Application or Session variables.
Also, don't store static lists in the database unless absolutely necessary. As a DBA, I have seen people store ridiculous things in a database such as month names or days of the week. Last time I looked those did not change!
Pick good defaults - Make the program usable in its default state. Most users do not read XML and aren't interested in editing it. By adding extraneous configuration settings you are only adding complexity to your application. Usable defaults are the way to go. If there are parameters that need to be modified by the end user then give them a user interface to change them.
Don't Overdesign - Every programmer has probably been guilty of overdesigning something. Sometimes we get tempted by fancy patterns and practices. In addition, some of us tend to abuse things like inheritance and abstraction. Most of the time its best to keep things simple. It is a rare occasion when I need to have more than 2 layers of inheritance.
Overdesign is also very common with databases. People get hung up on rules like "third normal form". Sometimes when you over-normalize a database is makes it impossible to query the data later on. If your application is going to require reports, sometimes its better to design the database with the reports in mind. In other words, let the reports dictate how the data is stored.
Code is not self commenting - I can't tell you how many times I have written a piece of code only to return to it a few years later and ask myself "What was I thinking? or "Why did I do that?". Nothing is worse then spending an entire day rewriting a section of code only to roll back the changes because you discover the original reason of why you wrote it that way.
And Finally, "Software is never finished. It is only abandoned" - One of my old co-workers told me this about 10 years ago and it stuck. The statement is absolutely true. There is always something that can be improved, optimized or re-written.
If you have any philosophies or rules that you developed over the years then please leave a comment. It is always fun to hear your thoughts!
