The Most Simple Solution

Intro
Two years ago, I was working on a Digital Signage project at a company which developed various softwares for another company in Germany. It's become very common and of course economic to outsource software projects these days. Some call it a win-win game because both parties gain a lot thanks to countries different states of economy.

The project was considerably big on paper. There were many servers and clients that needed synchronized communications and we had to consider ftp servers for massive file transfers. There were also different applications written in different languages that needed to cooperate. My job was to develop a solution to organize and manage all softwares, network communications, scheduling, etc. The cool part was me as the whole development team!

The Crazy Job
To be honest, before this project I couldn't imagine that complex softwares could be developed by a small team. I always remembered the enormous list of names at the end of computer games (I'd never forget The Neverhood!) when I encountered a professional software (but why there is no cast for those impressive softwares anyway?!).

The company I worked for was used to develop big and complex applications this way: A team of one or two programmers managed everything. It is a very good experience but truth to be told, it's sheer craziness! I had the advantage of choosing my favorite language for development and at that time I chose the VB.NET! Figure 1 shows a very rough schema of the main application just to make it more clear.

Figure 1. Main application schema

The Problem
OK that was a long story. The main part is about a communication problem between two different applications. The main application sent commands (download, view, suspend, shutdown, etc.) to clients. The clients then did the appropriate job. Each client supposed to have a viewer application which viewed graphical contents. I said 'supposed' because it was not developed since and it intended to be in pure C++.

The senior developer who was responsible for this viewer application was busy with another one-man project at the time so I had to do some parts virtually. The problem was simply the way two applications communicated. OK I know you have already listed possible approaches.* I also considered many: MSMQ, web services, various databases, COM Interop, etc. and surprisingly, the programmer refused any!

He demanded the communication mechanism to be as simple as possible. Actually simple for his side as he was busy. So I came to a very simple conclusion which the senior developer accepted without any hesitation. I created two folders at each client: Request and Response. The server created xml files in the Request folder and the client watched the folder for new requests (i.e files). After processing each request, the client deleted the file and optionally issued a response for the server to log through the response folder in the same way. I even created a simulated client which processed request under stress testing and it worked like a charm!

Conclusion
The project had many different parts and many technologies were involved. But this one was really fun! Sometimes you just can't use the most reliable and obvious solution and every solution won't work everywhere out of the box. I've seen many developers implement complex solutions for simple tasks which often use more system resources. The only key is to consider all possibilities without feeling shame! There are hopefully always alternatives and let them be simple but practical.


* I consulted guys at MSDN forum at the time. Here is the link.
photo: omidqrose.com