I have to admit that this post was inspired by a tweet from my arch something or other, Mike Acton. Mike and I have been known to have our disagreements, although I have come to realise that really these are more of a matter of perspective than anything: Mike tends to make statements without defining the scope for which they are valid. In this instance, the statement was that “Why? Data!” was the answer to everything. Although considering data is very important, it is not in my opinion the answer to everything. Data is a means to an end, and not an end in itself.
Have you ever had a child ask you “why?”, to which you answer only to have another “why?”. I would say that we should never chastise a child for asking why, even if it gets annoying. What the child is doing is exploring a fundamental to the concept of abstraction, and the ability to form abstractions is vital to mental development. A “Why?” question is a question that tends to take you to a more abstract domain. Think about it.
“Dad, why is that fire engine red?”
“Because it makes it easier to see”
“Why make it easier to see?”
“Because it has to move quickly and other traffic needs to get out of the way”
“Because it has to get to a fire quickly”
“To save people from being hurt”
“Because we don’t want people to die needlessly”
“Because that’s one of the values of society”
“Because we decided as a society to be that way”
“Because we care about each other”
“Because that way there should be more happiness in the world”
“Because…. erm…. Because….”
Although it is a rough rule of thumb, I do find it useful to consider abstraction this way. We started out with an implementation detail and data (fire engines are red) and ended up with a very broad and abstract concept (happiness). If you want to go the other way, it is useful to think of answering “how?”. Again it is a generalization, but has enough of a truth to it to be valuable.
In programming, “Why?” is generally what you ask as you head towards the customer of your software, and “How?” is generally what you ask as you head towards the actual implementation, and in our case the computer hardware is a major part of the how. I argue that you cannot really focus on only one end or the other; you have to work at both ends (a kind of top down and bottom up at the same time approach). Which leads us to what data is.
Data is an implementation detail, by and large. Caches, memory, cycles, registers, buses, DMA channels and whatever else are all important details, but they are all about implementation too. Data is not the product. Data is not the “why?”. Data is the “how?”. We want to make a video game that entertains? Well that’s the ultimate why. We want it to entertain on platform J? That’s requires moving data around, and that’s the ultimate how.
Thinking about data is vital, because without data there is no how. But it is very wrong to say that it is everything.
In short there are two things that make a video game: function and data. “Why? Data!” makes no sense to me in this context. It is “How? Data!”. And what about “Why”? Well it should be clear.
Why? Function! How? Data!