Why Do People Behave as if Asynchronous Processing is Easy?

Let’s see if you can spot the difference.  Your manager comes up to you and says

1. We need to get invoices from our order system into our treasury system.  What we were thinking was: we’ll get the order system to export its orders onto the file system, and the treasury system can read in the files and delete them when it’s finished.  How long should that take?
2. We need you to write a robust queuing solution.  How long should that take?

The answer is, of course, that there’s no difference, except possibly that you’re being asked to do a bad job in the first instance for which you will be blamed later.  If you want to get items from one system to another reliably, you need a queue.  If you don’t use one, you’ll end up writing one.

But it’s simple

The biggest problem I have with convincing people to use things like Retlang and MSMQ is the perception that they are somehow “complicated”.  In each case, something is perceived as being “easier”  (Messing around with threads and locks in the first instance, hacking around with files in the second.)  What we have here is an example of developers doing something they dislike non-technical managers for: treating anything they don’t understand as easy.

Put it this way, a friend of mine works in communications.  He writes a lot of complex asynchronous code, often bespoke and under serious time pressure.  When I showed him Retlang, he immediately jumped at it, because he understood the problem it was solving.  Most of us don’t deal with these things often enough to really understand the problem space.

If you don’t understand all of the things that can go wrong with a file drop copy or naive multi-threading code, you shouldn’t be writing it.  If you do, and you still don’t want to use a third party solution, you should really ask yourself what value you’re adding to your business.