A few more comments about ...Why Is the Phone on Fire?

Posted on March 14, 2011 by Tommy McGuire
Labels: software development, books
Since I gave such a ringing endorsement of If I Only Changed the Software, Why is the Phone on Fire? (at least as ringing as I plan on getting), there are a few more comments I can make related to the book.

Network protocols


HeaderAddressMessage IDGroup IDData LengthDataCRC
4 bytes4 bytes1 byte1 byte1 byte0-27 bytes2 bytes
One of Simone's chapters deals with a network-communication timing related bug that strikes somewhere close to my heart. Part of the problem deals with the format of protocol messages.

Raw Data Message Formats
Message Name/IDData LengthData Format
DATA_CHAR/51 byteSingle char
...
DATA_INT_ARRAY/111+(0-n)Num ints (1 byte), raw int data
...
Formatted Data Message Formats
Message Name/IDData LengthData Format
...
BLOOD_PRESSURE/2124Timestamp, 10 samples
bit-packed (4 chars, 1 int)
...
This format has a lot of excess redundancy. Consider that the data length is encoded in the message three times: as the message id, as the data length itself, and sometimes in the data itself. For example, the raw integer array includes a total data length as well as the number of integers. On the other hand, the raw messages are irrelevant; any actual use is going to need a dedicated message id, and the id determines the data size. Further, the data size may also be in the header, as an overall message length, and in the CRC, because anything that goes on the wire, or in the air, needs to be checksummed.
Since a part of the problem being discussed is a tight network-bandwidth bound, ditching the useless data length byte plus an unused byte in the data would allow another sample to be sent in the pulse-oxygen message, reducing the original bandwidth used from 120kbps and the solution's 29kbps to 27kbps, a reduction of about 6%.

(Strangely, Simone cites TinyOS in the discussion of the message format. I have no idea why.)

Tips


Despite providing another example of the Heavenly Emporium of Benevolent Knowledge, Simone's list of tips has some interesting features.

Find a sounding board (doesn't have to be a live person!) - talk through ideas to quickly identify good ideas and discard bad ones.

Surprisingly effective. Also found in The Psychology of Computer Programming, where Gerald Weinberg advised talking to a stuffed bear. Or you can try a rubber duck, according to Del.

Use visual aids (flowcharts, graphs, function call trees)....

The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth. - Niels Bohr.
I come from the land of Dijkstra, where flowcharts and such are frowned on, for good reason. However, visual aids can easily show parallel structures, or the lack thereof, in the system.

Play Computer.

Or don't. As I may have mentioned before, I view dynamic reasoning with roughly the same enthusiasm as flowcharts. Both have their uses, but static reasoning and more formal methods are usually more effective.

Think with your brain, not your debugger.

My disdain for debuggers occasionally earns me abuse, but they really should be a last resort, not a first choice.

Be clever.

I reiterate my earlier reference to Niels.
active directory applied formal logic ashurbanipal authentication books c c++ comics conference continuations coq data structure digital humanities Dijkstra eclipse virgo electronics emacs goodreads haskell http java job Knuth ldap link linux lisp math naming nimrod notation OpenAM osgi parsing pony programming language protocols python quote quotes R random REST ruby rust SAML scala scheme shell software development system administration theory tip toy problems unix vmware yeti
Member of The Internet Defense League
Site proudly generated by Hakyll.