If no-one else has already stated this law, then I’d like to claim it myself: Davies’s Law of Communications Programming (The Davies Postulate, Davies’s Principle?). According to the Davies Law, when you write some kind of communications code from a blank page, the test environment usually involves some existing device that already knows the protocol. Your challenge is to write enough code to establish a conversation with that device, which means the starting point is to write the most difficult transaction you will ever come across. Put simply:

To test a communications application, you have to write the most difficult part of the protocol first.


Opening a conversation is the hardest part, and that has to happen at the start.

For example, you want to use SS7/ISUP. What do you code first? The IAM, with its many parameters and tricky way of packing telephone numbers. You want to do SIP? Design the code to create an INVITE message, which means understanding how to build SDP as well as SIP headers. You’d like to start with “ACK”, but that doesn’t make sense. You want to do ISDN? First you have to build the SETUP message. In the days of SNA if you wanted to open a session, you’d have to code the BIND request right. It could take days.

Probably worse is when you don’t already have a working device to connect to: some years ago I had to write a file transfer client (a bit like TFTP) that used IPv6. I didn’t already have a working server, so I had to write that end as well in order to have something to test against. You also come across the same situation when you create a DLL wrapper around some old code in order to make it more friendly, for example for a Java client. Often you get stuck in a cycle of changing both your Java test rig and your C DLL both at the same time in order to fix problems you have created in the API. This situation makes you write the most difficult of the code part twice, once from each end! Perhaps this deserves a corollary:

To implement a new communications system, you have to write the most difficult part of the protocol twice.