+1 for Stanslaw Lem, especially for the real geeks in the crowd. Unlike many/most sci fi authors, Lem was trained in mathematics and knew his hard sciences as well. The Cyberiad is funny and charming, but His Master's Voice is one of my favorites -- a glimpse at the dark side of the scientific-military-industrial complex and the unexpected possibilities inherent in scientific discovery, as well as the limits of human understanding.

Lem's story Golem XIV (in the quirky "collection" Imaginary Magnitude) consists of a long monologue from a superintelligent, former-military AI. I found it one of the stranger, more beautiful, and more compelling pieces of sci fi I've encountered.

I have had thoughts along similar lines. In addition to the above suggestion, what if I could (for a fee),
- send email to an address and have it converted into a physical letter to be delivered to the receiver? (Saves cost of shipping except for "the last mile")
- have my mail scanned, delivered via email, and, when I click the appropriate URL, shredded or physically delivered?
I use an awesome multi-sheet scanner which has helped me go almost completely paperless. I would just as soon not receive any physical mail any more, with the possible and rare exception of hand-written notes (and checks, but ... PayPal, etc.).
I realize there are services to take care of things like this. But costs could come down if it was available nationwide in a standardized way. Cutting down physical delivery of mail (with its corresponding environmental impact) is one of those things I'd like to see government do (rather than leaving it to a mishmash of private companies).

I prefer to write code this way, too, and have found, to my surprise, that I find it more fun than not doing it (and not just because of the avoidance of the extra debugging pain). Furthermore, this approach leads to more modularity (un-modular code is much harder to test; google "dependency injection" or see this video). Lastly, if you base your implementation only on the tests your code needs to pass, it tends to be simpler in the end.

Python's "doctests" provide a handy way to pursue this kind of development; you put your tests directly in a "docstring" (multiline documentation comment) at the beginning of your class or function and specify exactly how it should behave, exactly as if were an interactive python session. You can then test all your edge cases explicitly in the comments for the code, providing not just a regression test but a fairly complete explanation of what the code does. This is one of the many reasons I prefer to develop in Python when possible.

I guess the reason I find it fun is that you "double your pleasure" of seeing your functionality grow as you iteratively add requirements and satisfy them; AND you are free to refactor ruthlessly because the tests "have your back" -- so the code can be that much better.