Let’s face it. No matter how much tuning one can do at various sub systems (Application Server, Web Server, Operating System, Database), when the code is bad, you are screwed. Poor coding can cost a company a lot, and in some cases can cost the company itself.
Before diving into the 9 blunders made by the development team, let me tell you that I have been a software engineer and I have personally made lot of these mistakes myself. It requires great deal of discipline to be vigilant about writing quality code. There is no other choice.
Without further due, here are the 9 blunders by the Development team that will make Production Support’s life miserable. Don’t make anyone’s life miserable.
1. Hard coding values
Don’t hard code configuration values like URLs, Directory locations, username/passwords etc in the code. Code is not the place for this. Store it in externalized property files. It seems simple enough but I have seen it over and over again that somehow some hardcoded value sneaks in and breaks when it goes to production. Managing configuration information within code is a nightmare. Don’t do it.
2. Excessive logging
OK. When you run the application in your local environment (PC), nobody cares what’s the logging level you have. Go ‘debug’ or ‘all’ if you please. But when it goes to production (or other higher environments), limit your logging to ‘INFO’ or ‘WARNING’. Excessive logging has 3 major impacts
a. It puts load on the Application (I’ve seen applications crawl due to excessive logging)
b. It can fill up file system and that can create issues for you application and other applications on the same server (Do you know what will happen when root directory of certain flavors of unix system fills up ? – that’s right. No one can login)
c. Troubleshooting will be like looking for needle in haystack (if the poor admin can ever get the log file to open)
3. Not closing backend connections
Well, with modern frame works, this issue is actually slowly disappearing (as the framework takes care of opening/closing connections). However, make sure you always ‘close’ the database connection so that it is released back to the pool. A common mistake is not closing the connection in the ‘finally’ block of a ‘try catch’. If here is a connection pool leak, your connection pool with be exhausted soon and your user will experience immediate slowness.
4. Mis handling large result sets from Database
You cannot load everything you read from the database to memory in one call. In some cases, obviously you will run out of memory. Instead implememnt some sort of ‘pagination’ and/or ‘lazy loading’ so that you don’t have to load everything in the beginning.
5. Underestimating production load
I always get this from the developer. ‘It works fine in my local environment. But when it went to production, it crashed’.
Yes, it is the job of the load testing team to test your application with production like load. But that does not mean that as a developer you write code that does not scale well (for example, it works fine for 1 user, but what happens when there are 500 users online simultaneously).
Always keep production load in mind and code.
6. Not considering portability
You don’t want to code anything that is related to local operating system. For example, executing a OS command (example: uname -a) from java and handling the output. What happens if the company decided to move to Windows from Unix ? Are you going to refactor hundreds of lines of code ?
7. Not considering cluster scenario
So, the code works fine in local environment where there is only one instance of your application is running. But this is not a gurantee to coclude that it will work fine in a clustered scenario (multiple instances of the same application). What if you have a scheduled job within the code ? Wouldn’t it run multiple times when have more than one instance ? What are the side effects of this ?
9. Packaging utility jar files in several places (Added bonus: various versions of the same utility jar in various locations)
The infamous ‘ClassCast Exception’ or ‘NoClassDefFoundException’ is most of the times due to the version mismatch of third party jar files. Make sure you only package one copy of the jar file.
Bonus Blunders 🙂 🙂
10. Swallowing exceptions
Please don’t swallow the exceptions. Stack trace is the most valuable troubleshooting information. On the other end of the spectrum don’t print the stack trace wherever you please. Printing a strack trace is a resource intensive process.
11. Not involving Middleware Administrators early
You could avoid lot of issues if you involve Middelware Administrator as early as possible in development cycle. They might proivde a perspective that you may not have.
Better code = Better Application = Happy customers
LIVE WITH ZEAL