Mike Acton recently gave a wonderful talk at CppCon about Data-Oriented Design. I wholeheartedly encourage you to watch it.
Inside this talk are specifics related to c/c++ and compilers… as you would expect from a c++ conference. But, more importantly (to me) underlying it all is a wonderful set of principles that are elegantly expressed by Mike Acton, this post is an attempt to summarize the language agnostic principles I took away from his talk, from the reference point of his “three big lies”.
The Three Big Lies
- Code is more important than data.
- Code should be designed around a model of the world.
- Software is a platform.
Lie #1. Code is more important that data.
Truth: Your main responsibility is to transform data, not designing code, solve the data transformation problem first.
“Everything is a data problem. including usability, maintenance, debug-ability, everything.”
- The purpose of all programs, and all parts of those programs, is to transform data from one form to another.
- The programmer is fundamentally responsibility for the data, not the code. The problem is data transformation, code is a tool.
- Only write code that has direct, provable value. It should transform data in a meaningful way.
- You can not future proof, this is a trap.
- If you don’t understand the data, you don’t understand the problem.
- If you have different data, you have a different problem, which requires a different solution.
- If you don’t understand the cost of solving the problem, you don’t understand the problem.
- If you don’t understand that hardware, you can’t understand the cost.
- Where there is one, there are many. Design around the reality of the data, not an idealized individual “widget”.
- The more context you have, the better you can make the solution. Don’t throw away context you need.
- This context can extend back to the birth of the data. Data doesn’t exist in a vacuum.
Lie #2. Code should be designed around a model of the world.
Truth: Code should be designed around the data, not some idealized model.
“Solving problems you probably don’t have creates problems you definitely do.”
- World modeling is the equivalent of self-help books for programming: trying to solve problems by analogy, trying to solve problems by story telling. These problems should be solved by engineering, which deals with the concrete realities of data transformations.
- There is no ideal, abstract solution to the problem.
- Hiding data is implicit in model building (some would claim that is even the point). This is bad. It trades (possibly) slightly better maintenance at the cost of understand the data. Understand the data is how you understand the problem. Additionally, world building implies a relationship to reality that simply isn’t there.
- World modeling leads to monolithic, unrelated data structures and transforms.
- World modeling tries to idealize away problems. It tries to simplify it beyond the reality of the problem.
Lie #3. Software is a platform.
Truth: hardware is the platform.
“Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs”
- Different hardware means different problems and different solutions.
- Obviously developing code for an ATI 5870 versus PPC versus X86 versus arm versus 6502 are all very different beasts.
- Reality is not a hack you’re forced to deal with to solve your abstract, theoretical problem. Reality is the actual problem!