10 thoughts on successful server programming

What defines succesful server software and how can it be programmed?

How to program server software successfully

Everyone uses server software nowadays, at least in the internet, but most time people are not aware of it. Therefore "successful" server software is boring. Not the technology or the creation process itself, but server software is succesful when it behaves boring. Or, in other words, it simply works. Most times you do not know it's there and if it behaves as it should one tends not to see it.

So at first, a definition of "server software" would be helpful. Server software(s) are programs that do not run on your computer directly. Results of input are computed on another peace of hardware but then the results are shown in your own program (or internet browser, this very page you are reading is nothing else than a computed result from the servers of blogspot.com).

But how are programs prepared to work in the daily server world? Just a few (apparently obvious) thoughts to achieve this goal.

10 thoughts on successful server programming

1. Be aware that a server program or script is not comparable with software running on your computer at home. Server software has to run self-sufficient to a high degree.
2. Think of an appropriate logging to relieve later-on forensic fault diagnostics. Better to log too much than nothing, users who access your server will do this in ways you never thought of while programming it. And there is a good chance that you need to narrow down what exactly happened.
3. Use all features your programming language provides to write solid software. If exception handling is available, use it. Finally-blocks to clean up your code? Definitely. And there is much more you can utilize, from assertions to the usage of complete testing systems etc.
   
4. In any case avoid memory leaks. If you program C / C++ be very careful, but even if you use Java / .NET or scripting languages this may get an issue for long running server software (just assume that a collection of data in Java / .NET will only get longer and longer and never shorter).
   
5. When you use external resources (i.e. databases, networks or file systems) be aware that they may fail. The least should be an explanative error message for your users. The best would be an email notification to the administrator and a retry / recover of the failing system automatically (to a second database, for example). The parts in programming I need to rely on external resources are the parts I spend the most time developing them, create fallbacks for or even use logging at most.
   
6. Try to get the configuration as precise as possible. The configuration(s) of your systems are the base your software is running on, keep it as simple as possible and as complex as necessary. To ease your way changing your configuration later on simply follow an old saying from Antoine de Saint Exupery: "Perfection is reached not when there is nothing left to add, but when there is nothing left to take away."
   
7. If possible try to set up a test system. If you do not have a spare server for that, do it on your own (development) computer. The moment you notice erratical behaviour is the moment where you do not want to mess around setting up a system to replay and find the error.
   
8. Make Backups. Nobody wants backup but everyone cries for recovery. Do not forget that you write server software and, in case something bad happened, you have to be up and running as fast as possible. Backups may help to recover fast, then you got time to search for the problem.
   
9. If you follow all these steps do not forget that "releasing" has other implications for server software. The good news is that you may not need to release client-software on hundreds or thounsands of computers. The bad news is that you might have to take your server down to release new program(part)s and believe it or not: Users don't like that ;-) . So releasing should be as fast and stable as possible. Best would be that it is rollback-able to an older (working) release.
   
10. Alas, there is one very unpopular thought left: Document it. Start documenting the structure (i.e. involved server machines, a top-down documentation of the different modules/parts of your software etc.) and the programming code inline itself. There are many guides and tools out there that help you get your documentation right, search and follow the ones that help you most here.
    

Though this all sounds pretty obvious it is astounding that you nearly never see systems that follow all this tips. Even if you want to you may not be able to follow all of them because of restrictions from the outer world (timelines, new "prio zero" features needed yesterday etc.). But often it helps just to keep them in mind in your daily work and introduce them eventually. And now, happy server-software-coding!