Whole Systems Thinking and Pesky Details
I wasted an hour today trying to get an email signature line just the way I wanted it. The mail program I use is Eudora. I use it in paid mode. I’m not picking on Eudora so much as I am picking on the state of software tools in general (I’d love to hear your favorite tool horror).
I wanted to create several different signatures for different occasions: one for marketing to local clients, one that is just my "standard tagline", etc. As part of my signature I wanted a line that included links to my website and blog on a single line:
website: www.wirfs-brock.com blog: www.wirfs-brock.com/rebeccasblog.html
That worked just fine for my standard signature file, where these were the only links. But then I wanted to create another signature which included these links followed by lines with links to upcoming public classes. Each class would be listed on a single line containing a link to the registration page. When I inserted these lines into my file, I encountered problems. The signature looked just fine when created and displayed as I was composing email. But somewhere in the process of sending and receiving the email, that first website link got mangled. I had encountered yet another case of what Scott Meyer’s refers as the keyhole problem. I still don’t know if this is a send or receive error, but trying to fix this problem drove me nuts.
Instead of a well-formed link, the link in incoming email was extended with spaces, breaking it. Needless to say, being a software geek, I vowed to tame this problem. I performed twenty or so different experiments over the next hour. I inserted tabs instead of spaces between my website and blog link. This worked, but the formatting was ragged and I don’t like inserting tabs into messages as some people’s mail systems don’t uniformly display text with embedded tabs. I put the website and blog links on separate lines. This worked, but it made my signature longer. I inserted one tab and spaces after the website link. This worked but had resulted in a ragged signature line that looked unprofessional. I copied the line with the links that worked from my other signature file and pasted it into the second signature one (of course this didn’t work, what was I thinking?). I tried re-specifying the links (this didn’t work either). I moved the broken-linked lines to after the single link lines in my signature file . This largely worked, too, except the spacing between the website link and the blog link came back with an extra space between them (making it a ragged line).
I then got the bright idea of creating a signature file in a fixed font, instead of Ariel. This worked. But I didn’t like how Courier looks. Too clunky. When I changed my signature file back to a font more appealing than Courier, Eudora apparently let me change my signature file, but it refused to pick up the new font information as specified in that file. Even rebooting my mail program didn’t correct the problem (obviously it was caching the font style and not really looking at the font specified in my signature file). I was headed even deeper into the weeds... At this point I decided to give up as I had several approaches that would work OK, even if they didn’t let me format the signature file exactly as I wanted.
All the trouble I had making a signature file made me want to chuck Eudora and move to another mailing tool. But I haven’t, just yet. I’m a healthy skeptic. Each software tool I use has its own peculiar quirks and annoying irritations. (But send me some convincing arguments about why I should move to another mail program and I’ll seriously consider it). Is this because developers are lazy or don’t care about quality? I suspect that most developers do not purposefully go about building quirky software. Yet somehow quirks creep in. There are myriad reasons. For one, most software is developed by teams. Each person has their own piece to implement and the system as a whole isn’t "owned" by anyone. This traditional view of software development is changing with agile teams. Collective ownership, one of XP’s core practices emphasizes teamwork. The more eyes that look at code, the better. But still, you need to pay attention to the system as a whole, even while paying attention to details.
You cannot eliminate these all bugs, but you can certainly waste time writing dumb little unit tests that don’t add any value. Uncovering quirky system behaviors requires spending your testing time wisely. It isn’t enough to write one simple test and declare, "setting up a signature file seems to work." My quirky bug spanned multiple contexts: composing a signature file, sending email, and then receiving correctly formatted mail. Exploratory testing is a practice worth considering. It involves spending some time poking around, looking for stuff that just might not work. But developers need to take more responsiblity for overall system quality, too. Just checking that your code works isn’t good enough.
- Previous: Good enough domain models
- Next: Rock, Paper, Scissors--oh Sh#$%!