What's with the biological imagery above? Are you one of those nuts who fantasize that computers are alive? Or are you just trying to borrow the grandeur of success in genetics to pump up the mystique of your own field of study? How can a DNA molecule say anything useful about computer data?

No, computer systems aren't alive. The biological imagery and DNA molecule support a nice analogy that says bytes in computers are like atoms in biology. Both are simple and lifeless, but can be joined in big patterns. Solid objects consist of atoms, and data objects consist of bytes.

The DNA molecule shows a sudden change happens at an atomic level between lifeless matter and something more that uses matter as an underlying substrate. It's not the atoms and molecules in DNA that imbue life. Instead the information is present somewhere in the organization.

Right, and the info in DNA is useless by itself. It only makes sense in the context of a host of other biological materials interacting with DNA molecules. DNA serves a function within cells only with other molecules in its company.

The same thing applies to both code and data in computers. They depend on the presence of more code and data to provide additional context. Much art in computers involves keeping understandings suitably aligned. We avoid confusing which bytes mean text and which bytes mean images, etc.

I have this fear you'll tell me about ones and zeroes again. I know everything in computers is binary ones and zeroes, but I don't care. I can use my computer without considering ones and zeroes. So why tell me about bits and bytes now? It all seems arbitrary. What do I really need to know? How often do you developers think about ones and zeroes?

We rarely think about ones and zeroes per se, so we're more like you than you might think. We often write code doing arithmetic with data, where we know the representation of ones and zeroes is important, but we don't need any details. I can write hash functions without knowing ASCII codes.

When we want ones and zeroes we can see them, but it's rarely necessary. I drive to a local grocery store all the time, and I neither use a map nor look at the street names. I know where I'm going, so I just drive. If I wanted to notice street names I could do so. But I have no desire nor reason.

We tell you about bits and bytes now so you know where it all stops at the bottom, and so you have some feel for size. It helps to have some intuitive feel for size in small data, just like it helps to know the size of a dollar when shopping. Would you want to pay $500 for a cup of coffee?

Compared to atoms in physics, bytes in computers are simple. We don't have scads of mysterious subatomic particles. Each byte has the same simple structure. Every byte has eight ordered bits. (Vex, keep quiet.) You can look at a byte as eight bits, or as a small integer in the range zero to 255.

But you don't need to know that. You need only know a byte can distinguish few things, since it can have only 256 different values. When you have more things, a byte is too small and you'll need more. For example, when writing text in Unicode, each letter uses two bytes instead of just one.

We once wrote text in ASCII (American Standard Code for Information Interchange) nearly always. This is an arbitrary code that assigns different small integers to mean different things. For example, 0x42 in hex denotes the letter 'B'. But ASCII has a very small repertoire for letters. It's for Roman Latin alphabets.

As a standard ASCII is now extremely pervasive, which makes it very convenient. Unicode is a newer standard with a much larger standard repertoire for letters, because it can distinguish 64K (i.e. 64 * 1024) different letters using two bytes.

But I hate Unicode with a passion even if it's politically correct to support alphabets I don't care about. It doubles the amount of memory I need to represent text. And using Unicode is a performance nightmare because I need a virtual machine now in places where CPU arithmetic worked fine for ASCII.

Okay, I understand a view of text that formats can undergo technical change. But can you get back to why I should care? How does this affect my data and where it lives? All data is not text, is it? You never fully answered my question about what I really need to know about bits and bytes. Do I really need to know a byte has eight bits? And what do those names mean anyway? Bit and byte sound so arbitrary.

Okay, what you really need to know is what can go wrong. To understand any potential risk of loss to your data, it helps to know what would make it corrupt. That might help you grasp how a vendor is trying to prevent this, and how this affects the movement of your data. Many issues involve bytes.

You don't need to know a byte has eight bits. That's arbitrary, but it doesn't change anymore. It's not much more interesting than knowing decimal numbers use ten digits from 0 to 9. The names for bits and bytes are somewhat arbitrary. Bit once stood for binary digit in the beginning, if that helps.

Let's go back to the risk of data loss. The risk of loss in data composed of bytes is similar to the risk of damage in DNA composed of atoms and molecules in biological systems. Almost any change to a DNA sequence can damage it. DNA info is composed of a sequence of pairs from a repertoire.

Of course, DNA seems to have some noise, so some changes do not cause damage. But let's ignore that and work with the model that any change is damage. Swapping old DNA pairs with different new pairs is damage. So is cutting pairs or adding pairs. Similar things in data can also be damage.

Computer data is not only sensitive to bit values, but also to number of bytes and their relative positions. Altering bytes, or moving them around, or changing the length of a sequence can all drastically change meaning, sometimes to the extent of making data completely unintelligible.

So computer systems often focus on making perfect replicas of data to prevent loss. Changing data just a little can have small to large effects. A change in content might make a barely perceptible change to users. But changes in metacontent might cause any content described to become unreadable.

When text formats or other formats undergo technical change, this can affect the integrity of Yen's data. This is because Yen's data moves around, and the code using the data might not be the same everywhere. The more standards change, the bigger chance code systems vary in operation.

A computer system might succeed in making perfect replicas of data bytes. But the code in a receiving system might assign slightly different meanings to the bytes. This would make the data seem different in a receiving computer even if the bytes were identical to those sent from a source.

This affects where Yen's data lives, because Yen's data can vary in meaning in different places, even when perfect copies are passed from point to point. This is more likely to happen when standards undergo technical change than otherwise.

Basically, the longer your data lives, the bigger a pain it is to me. This is because the code on your computer changes when you install new software. And the code on my server changes when I write new software or buy into the hottest new fad. Either can alter the meaning of your old data.

After a long period of technical change, Vex can lose sympathy with your desire to preserve old data. He thinks you should have upgraded to the newest things long ago. If you suffer as a result of not upgrading, he thinks this is partly your fault.

You make it sound like a bad thing that I want Yen to upgrade all his software. I mean c'mon. He might be using products written a couple years ago, or (shudder) even as long as five years ago. Get real! The world doesn't stop just because Yen stopped shelling out bucks for new software.

You make it sound like you have no duty unless I pay regular software fees on a subscription model, whether or not that was our original understanding. When I pay for something I expect it to work. Now I see all software slowly decays over a few years. Does the free web app work that way, too?

Hey, babe, I live on internet time. By now I think in terms of months instead of years. I'll guarantee your data until next quarter at the very least. The informal industry statute of limitations gets shorter all the time. It doesn't last much longer than it takes me to go find a new gig.

I can control my anger. I'm counting to ten. Ah, somebody distract me so my blood pressure goes down again. Roz, tell me your business model doesn't have planned obsolescence built into it like Vex's. Are you shipping, and how much does Rozware cost these days?

Whoa, don't get all testy! Geez, users get awfully uptight. I gotta make a living you know. Just because I give you something for free doesn't mean I have no plan to shake you by the ankles and collect all your spare change. You keep me in snappy threads and cars, and I'll watch your data.

Sorry, we're not shipping yet. Avoiding obsolescence is complex, and I only see good results from following a two pronged approach. If we make data available in both long term and short term formats, we can split our efforts between protecting old assets and making new technical progress.

The cutting edge involves a bit of chaos, and this chaos eats away at the safety of your data, just like the ocean eats away the coastline more during storms than other times. But we can hedge the risk by paying for a bit of redundancy in the system for storing data. It makes software a bit more costly.

For example, we might use XML as a safer and lower rate of change format, if we can see how to avoid thrash in document schema standards. If we make data self descriptive enough, it's hard for content to become unreadable. That's one prong.

The other prong of the approach is to use more experimental formats in our chase for more performance and utility. As long as your data is not trapped in less stable formats, change caused by technical evolution will not put your data at risk. That way innovation doesn't hold you hostage.

But two prongs will make our development more expensive. It's not easy to fully support two entirely different storage approaches with equal levels of fidelity and code quality. We must make our code abstract to achieve this. But we actually think that abstraction can improve the code quality.

In the time we ship one system done right, Vex might ship two squirrelly ones and have an IPO under his belt as well. Maybe we can split the market with Vex. He can chase the easy money from folks new to the scene, and we can chase the folks looking for more quality and support.

Heh, but you forgot one thing. I'm also filing patents left and right as fast as I can put up legal fences across the landscape. So you losers will walk a minefield the whole way, with me suing you for license fees you can't afford. Maybe I'll let you sharecroppers keep some of the harvest. Hah! Man, I love the law when it works so well in my favor.