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

Posted on March 14, 2011 by Tommy McGuire

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

Header	Address	Message ID	Group ID	Data Length	Data	CRC
4 bytes	4 bytes	1 byte	1 byte	1 byte	0-27 bytes	2 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/ID	Data Length	Data Format
DATA_CHAR/5	1 byte	Single char
...
DATA_INT_ARRAY/11	1+(0-n)	Num ints (1 byte), raw int data
...
Formatted Data Message Formats
Message Name/ID	Data Length	Data Format
...
BLOOD_PRESSURE/21	24	Timestamp, 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.