I think it’s a specious analogy. Programming isn’t a game any more than any other art, craft or engineering discipline is a game. You can certainly view “the market” as a game, but the aspects of programming that matter to a programmer aren’t any more relevant to that than they are to the business of selling anything else: fitness for purpose, price point, speed of iteration, customer service, etc. These are not aspects of programming per se, they crop up in programming businesses like they would in any other business. Being a master carpenter doesn’t automatically make you a successful furniture manufacturer either, and being a lousy one doesn’t preclude you from having a successful furniture business either.
Over lunch, I realized I actually find the “winners’ vs. losers’ game” concept interesting, so I’m glad I read the article for that.
This is an excellent point, and I certainly didn’t intend to trivialise programming. Programming is as much an art form as it is anything else. In fact, I think Knuth sums it up nicely in this quote.
We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty.
What I was trying to explore in the piece is the idea that, like in a game, as programmers we normally have some sort of goal. In tennis, that goal would be to win the match. For programmers, that goal may be to produce high quality software. In a lot of scenarios, perhaps the best strategy to reaching that goal is to focus on avoiding actions that frustrate your attempts. In tennis, that would be try to avoid hitting the net, rather than focussing on trying to outsmart your opponent with a clever backhand. In programming, that might be try and be extra careful to avoid bugs, rather than implement some very complex algorithm.
It is likely not a perfect analogy, but similarly to you, I think the “winners’ game vs. losers’ game” is a really interesting concept, and I believe there is something in there relevant to our field.
I like this idea of trying to succeed by winning points, but I feel like programming isn’t even the game most of the time. A lot of software fails before it even gets to the coding stage with vague or ill-conceived notions of the goals of the actual project.
Well, yes, and this is a part of the point: if implementation affects the outcome, it is more probably because it was just too bad. Otherwise managing lock-in beats features anyway…
Cool. So my caffeine didn’t kick in before I posted and I’m on the page as the author. Nice. My point which I share with the author, was that you can be in a situation as a developer, where it’s impossible to win regardless of the quality of your implementation. If the company is producing something no one wants, you can’t win. You can definitely tank a possibly successful product with a horrible enough code base, but I’ve seen multiple successful products with very questionable codebases when open sourced. As a developer, you can’t force success, but you can guarantee failure.
If these code practices were that bad, you would know the code quality is bad without open-sourcing, just from the bugs!
When you cannot win the top-level game, it is often not your game to play anyway! Just play well whatever subgame you do have access to, and prepare to avoid being hit too badly when the entire thing crashes…
(As a sad remark, of course you can win if the company produces something noone wants. It just needs to produce something someone with resources wants to force onto others.)
Bernard Suits wrote a lovely book gradually approaching a necessary and sufficient definition of a game as:
engaging in an activity directed towards bringing about a specific state of affairs, using only means permitted by rules, where the rules prohibit more efficient in favour of less efficient means, and where such rules are accepted just because they make possible such activity
The book is worth reading in its own right, and I think helps understand that neither programming nor software engineering are a game.
The key reason is that in a game you erect elaborate constrictive rules that everyone knows exists, and everyone knows everyone else knows, etc., and we act within the confines of the rules to engage in the activity. In software engineering, in my experience, often its the rules themselves that are most in doubt. What does the customer want? What does the customer need? What is a definition of security in this context? Is this system “fast” enough? What does fast mean?
In software engineering there is so much doubt about the desired “state of affairs” and “rules” that coding is, to be frank, the trivial part of the exercise. Rather than being a winner (most test coverage! minimize computational complexity!), or being a loser (stop writing bugs! write end-to-end tests!), you spend most of the time defining the problem space, understanding who needs what and why and by when, and then coming up with a set of milestones where you gradually build up confidence and learn more as you build towards a solution.
Also software engineering is ruthlessly efficient. If the most efficient solution is to do nothing, or indeed get rid of something, that is the path forward. Haha this reminds me of that classic line from War Games: “Strange game. The only way to win is not to play.”.
This may reflect my personal experience, and I definitely did not feel this way as a junior developer when I first started working.
That sounds like it’s a good definition of game in conversational English, but it is definitely not the definition of a game in game theory (one of the core areas of mathematics in computer science), which is how I interpreted the article.
I think this is a really good point, though one could definitely argue that some project management philosophies can turn “erect elaborate constrictive rules” at times! On the whole, I would agree that software engineering is not a game. I have tried to clarify my thinking on a comment above
coding is, to be frank, the trivial part of the exercise.
I think that’s the author’s point. You usually can’t make the business work through brilliant code alone, but you can kill it by failing to meet some floor quality level. It’s a “loser’s game” because returns to excellence are low while the cost of inadequacy are high. This means the outcome is driven by reducing basic errors more than reaching unique accomplishments.
Nice clickbait title built around using a stretched definition borrowed from a distant time and place. Not even analogous to the original because programming isn’t a competitive sport where you play against another person.
That’s an interesting point of view. Can “winners game” and “losers game” can even be applied to a non-competitive field such as programming? I guess that in this case, this depends mostly on how we measure the points.
I was thinking the same thing. For this analogy to work, you need to assign points to a winning or losing category. And this is pretty arbitrary (ex. using N+M string concatenation might be a lost point, or completely neutral depending on the application).
There are also plenty of competitive games (like soccer) where most points can’t be objectively assigned to the ‘winning’ or the ‘losing’ party.
The article certainly raises more questions than it answers. But it seems most people on lobste.rs can relate to the author’s point of view.
But by that measure, programmer can also be like a pro and amateur tennis player. A winner will score more features then the opponent, be faster with bug fixes and all. A loser will be making mistakes, refactoring, picking ineffective tech or architecture etc. Why is programming only a losers game?
It entirely depends on who’s playing. Tennis becomes winners game only when the players stop making mistakes. Looking at the current state of programming, it’s closer to the losers game.
But it’s the same with tennis, it’s a losers game because most people lose, right? There’s only one winner at the end? Like with programming or with anything else.
I mean, what does it even mean to win or lose? If it’s about selling your product - that’s not very programming-related. If it’s about, I don’t know, keeping the servers uptime at five nines, or having less then X bugs or y% coverage, then you might have something to measure up against, to see if you “won”. But even there, it’s not clear what you’ve won, since you were the one setting the rules in the first place (or well, the business did, and you said it can be done). My point is that I somewhat can understand this perspective, but it doesn’t really apply and the analogy for me doesn’t work. I can’t have a winner or loser tag if I don’t have anybody to compete with.
I mean, what does it even mean to win or lose? If it’s about selling your product
The author describes it as “producing high quality code”, so let’s hold on to that. So something becomes a winning game when you can stop making mistakes. What does this imply? Imagine you have to write a huge multithreaded application in C++ and it’s going to be used by millions of endusers and you have to get it out yesterday. This seems like a pretty good example of a losers game.
So how can we transition to a winners game? Improve the factors which influence code quality, it seems. Maybe user better technology, maybe get more time to develop, etc.
The point is a bit more subtle than “don’t write bad code”. It’s “make less mistakes than your competition”, which is actually a very different place to come from, and implies almost a sense of just keeping above the game, and that one might be able to get a lot out of focusing on a handful of things that are causing most of your mistakes, rather than just Not Writing Any Bad Code.
I would extend that to “make fewer basic mistakes than your competition.”
You’re more likely to kill your business by screwing up a database backup or password storage than you are to double your revenue with a 10% more efficient application.
Of course, what the basic mistakes are and how to avoid them is an exercise left to the reader!
Please read the post before you comment. Comments based only on the title, especially inserting a hyperbolic claim like starvation, don’t typically lead to very good conversations.
It classifies the games into winners games where one needs to win by succeeding at more posotove feats than the competition, and losers games where one needs to win by making fewer mistakes.
If I am a professional programmer I score more positive points than the competition when the product sells (for some definition of sell).
If I am an amateur programmer, I may occasionally have the brilliant buzzer-beater, which I will remember for all my life (“once upon a time I wrote a 100 line SQL query”), but essentially I am not making a living out of it.
Hence, if it puts food on the table it is a winning game. That is my POV.
I have written a ton of stuff where I needed to negotiate the scope and then the thing that mattered most was having few enough problems, not doing something better — just to agreed spec is fine. It was paid work.
You can say that the outcome was winning; the point of the distinction the article makes is that it was winning by default, winning by not losing and getting to the completion.
I have also written code where you need to win by scoring positive achievements, it surely is a different activity, often with a slightly different feel. (Whether paid or purely for fun) Even if the avoid-negatives code has some positive achievements later allowing it to survive further evolution.
This reminds me a little bit of the -etic and -emic distinction from (among other things) linguistics. The idea of studying something from the outside looking in (phonetics studies how different sounds are used to communicate across languages / “From outside” the context of a language) and from the inside looking out (phonemics studies how a particular language uses sounds to communicate).
I think the rhyme here is found in the intrinsic/extrinsic distinction – a ‘losers’ game is won due to extrinsic (outside our control) factors, just like phonetics studies how sounds work separate from any particular implementation; and a ‘winners’ game is a game won due to intrinsic factors (just like phonemic studies the use of sound internal to a language).
I don’t know that there is much more relevance than the fact that these things seem similar, but it’s at least interesting enough to me to warrant a mention.
I’m really struggling with this “winner’s game” vs. “loser’s game” distinction. I don’t understand how the outcome of an amateur tennis game is “determined” by the loser hitting the ball into the net more times than the winner when you can just as easily say it was determined by the winner successfully hitting the ball in the court more times than the loser… Or why is a pro game determined by the winner acing the ball more times than the loser, and not by the loser failing to ace it as many times as the winner?
In a “losers game”, you win by never dropping below some threshold for performance.
In a “winners game”, you win by performing above some threshold.
For most software, the difference in value delivered between “buggy” and “works” is greater than the difference between “works” to “and it’s amazing”; thus, it’s a “losers game” in that the key is to consistently not ship bugs.
For tennis:
Amateurs win points by repeatedly returning shots until their opponent messes up. Dropping below ‘minimum acceptable’ means hitting the ball out when they could have hit it in (an ‘unforced error’).
In a pro game, ‘unforced errors’ are rare enough that the commentators spend a minute talking about them when they happen. The professionals simply don’t make that kind of mistake often, so points are won by actively creating a situation where the other player can’t respond (eg rapidly switching the ball to the opposite side of the court so their opponent can’t get across in time).
I think it’s an interesting perspective, but I disagree with the dichotomy. There’s only one game: make one of your opponent’s mistakes the last mistake of the game. I have heard this in chess (it’s not who makes mistakes, it’s who makes the last mistake), and when you compare to Fritz/Stockfish/&c, you can clearly see how much of a mistake each move was.
Professional tennis players stroke the ball with strong, well-aimed shots… Errors are seldom made by these splendid players.
No, I disagree. Errors are often made by professionals, it’s just that you can’t perceive the error. Pretty much every time Serral wins a StarCraft final, and they interview him after hardly dropping a game, he says his play was “sloppy”. That’s (partly) why he’s the best. Obvious errors are seldom made, sure, but that doesn’t make 2 games.
It prevents you from making some kinds of mistakes, and it’s great, but it needs to come after a significant amount of fit-finding (prototypes, user research, etc), and the programmer needs the full context of the fit-finding (that is, they need to do it, not receive a report) from someone.
Most points are lost while deciding what to build.
Probably the least glamorous part of programming I’ve come across is the large amount of “Reshape data from X format to Y format” that can happen in several layers in an enterprise software, and often has to be done by hand. The only way something like that becomes challenging is if there are some strong performance constraints. The sort of thing that ORMs try to reduce, for one.
Good point. A friend suggested that algorithms may fit this least glamorous group as well. I agree with that but it is like a doctor avoiding blood during surgery =)
I’m not sure I agree, to be honest. Algorithms work may not be externally glamorous, but it’s either heavy research (in the case of trying to build new ones), or well defined, but potentially tricky (in the case of implementing existing ones). Both cases cater to what is often a core engagement of software development for its practitioners (solving puzzles or passing a well-specified test-suite)
This is one of the key goals for activefacts - being able to combine a shared logical schema with descriptions of serialisations to generate the transforms between those formats. The foundation is there but it needs a good serialisations model.
I think it’s a specious analogy. Programming isn’t a game any more than any other art, craft or engineering discipline is a game. You can certainly view “the market” as a game, but the aspects of programming that matter to a programmer aren’t any more relevant to that than they are to the business of selling anything else: fitness for purpose, price point, speed of iteration, customer service, etc. These are not aspects of programming per se, they crop up in programming businesses like they would in any other business. Being a master carpenter doesn’t automatically make you a successful furniture manufacturer either, and being a lousy one doesn’t preclude you from having a successful furniture business either.
Over lunch, I realized I actually find the “winners’ vs. losers’ game” concept interesting, so I’m glad I read the article for that.
I agree with this. Software and programming are closer to art than they are game.
Modeling software creation as a game quickly results in some obviously bad conclusions, like measuring lines of code output.
This is an excellent point, and I certainly didn’t intend to trivialise programming. Programming is as much an art form as it is anything else. In fact, I think Knuth sums it up nicely in this quote.
What I was trying to explore in the piece is the idea that, like in a game, as programmers we normally have some sort of goal. In tennis, that goal would be to win the match. For programmers, that goal may be to produce high quality software. In a lot of scenarios, perhaps the best strategy to reaching that goal is to focus on avoiding actions that frustrate your attempts. In tennis, that would be try to avoid hitting the net, rather than focussing on trying to outsmart your opponent with a clever backhand. In programming, that might be try and be extra careful to avoid bugs, rather than implement some very complex algorithm.
It is likely not a perfect analogy, but similarly to you, I think the “winners’ game vs. losers’ game” is a really interesting concept, and I believe there is something in there relevant to our field.
I like this idea of trying to succeed by winning points, but I feel like programming isn’t even the game most of the time. A lot of software fails before it even gets to the coding stage with vague or ill-conceived notions of the goals of the actual project.
Well, yes, and this is a part of the point: if implementation affects the outcome, it is more probably because it was just too bad. Otherwise managing lock-in beats features anyway…
Cool. So my caffeine didn’t kick in before I posted and I’m on the page as the author. Nice. My point which I share with the author, was that you can be in a situation as a developer, where it’s impossible to win regardless of the quality of your implementation. If the company is producing something no one wants, you can’t win. You can definitely tank a possibly successful product with a horrible enough code base, but I’ve seen multiple successful products with very questionable codebases when open sourced. As a developer, you can’t force success, but you can guarantee failure.
If these code practices were that bad, you would know the code quality is bad without open-sourcing, just from the bugs!
When you cannot win the top-level game, it is often not your game to play anyway! Just play well whatever subgame you do have access to, and prepare to avoid being hit too badly when the entire thing crashes…
(As a sad remark, of course you can win if the company produces something noone wants. It just needs to produce something someone with resources wants to force onto others.)
Bernard Suits wrote a lovely book gradually approaching a necessary and sufficient definition of a game as:
The book is worth reading in its own right, and I think helps understand that neither programming nor software engineering are a game.
The key reason is that in a game you erect elaborate constrictive rules that everyone knows exists, and everyone knows everyone else knows, etc., and we act within the confines of the rules to engage in the activity. In software engineering, in my experience, often its the rules themselves that are most in doubt. What does the customer want? What does the customer need? What is a definition of security in this context? Is this system “fast” enough? What does fast mean?
In software engineering there is so much doubt about the desired “state of affairs” and “rules” that coding is, to be frank, the trivial part of the exercise. Rather than being a winner (most test coverage! minimize computational complexity!), or being a loser (stop writing bugs! write end-to-end tests!), you spend most of the time defining the problem space, understanding who needs what and why and by when, and then coming up with a set of milestones where you gradually build up confidence and learn more as you build towards a solution.
Also software engineering is ruthlessly efficient. If the most efficient solution is to do nothing, or indeed get rid of something, that is the path forward. Haha this reminds me of that classic line from War Games: “Strange game. The only way to win is not to play.”.
This may reflect my personal experience, and I definitely did not feel this way as a junior developer when I first started working.
That sounds like it’s a good definition of game in conversational English, but it is definitely not the definition of a game in game theory (one of the core areas of mathematics in computer science), which is how I interpreted the article.
That’s gone straight on my Goodreads list!
I think this is a really good point, though one could definitely argue that some project management philosophies can turn “erect elaborate constrictive rules” at times! On the whole, I would agree that software engineering is not a game. I have tried to clarify my thinking on a comment above
I think that’s the author’s point. You usually can’t make the business work through brilliant code alone, but you can kill it by failing to meet some floor quality level. It’s a “loser’s game” because returns to excellence are low while the cost of inadequacy are high. This means the outcome is driven by reducing basic errors more than reaching unique accomplishments.
Nice clickbait title built around using a stretched definition borrowed from a distant time and place. Not even analogous to the original because programming isn’t a competitive sport where you play against another person.
That’s an interesting point of view. Can “winners game” and “losers game” can even be applied to a non-competitive field such as programming? I guess that in this case, this depends mostly on how we measure the points.
I was thinking the same thing. For this analogy to work, you need to assign points to a winning or losing category. And this is pretty arbitrary (ex. using N+M string concatenation might be a lost point, or completely neutral depending on the application).
There are also plenty of competitive games (like soccer) where most points can’t be objectively assigned to the ‘winning’ or the ‘losing’ party.
The article certainly raises more questions than it answers. But it seems most people on lobste.rs can relate to the author’s point of view.
But by that measure, programmer can also be like a pro and amateur tennis player. A winner will score more features then the opponent, be faster with bug fixes and all. A loser will be making mistakes, refactoring, picking ineffective tech or architecture etc. Why is programming only a losers game?
It entirely depends on who’s playing. Tennis becomes winners game only when the players stop making mistakes. Looking at the current state of programming, it’s closer to the losers game.
But it’s the same with tennis, it’s a losers game because most people lose, right? There’s only one winner at the end? Like with programming or with anything else.
I mean, what does it even mean to win or lose? If it’s about selling your product - that’s not very programming-related. If it’s about, I don’t know, keeping the servers uptime at five nines, or having less then X bugs or y% coverage, then you might have something to measure up against, to see if you “won”. But even there, it’s not clear what you’ve won, since you were the one setting the rules in the first place (or well, the business did, and you said it can be done). My point is that I somewhat can understand this perspective, but it doesn’t really apply and the analogy for me doesn’t work. I can’t have a winner or loser tag if I don’t have anybody to compete with.
The author describes it as “producing high quality code”, so let’s hold on to that. So something becomes a winning game when you can stop making mistakes. What does this imply? Imagine you have to write a huge multithreaded application in C++ and it’s going to be used by millions of endusers and you have to get it out yesterday. This seems like a pretty good example of a losers game.
So how can we transition to a winners game? Improve the factors which influence code quality, it seems. Maybe user better technology, maybe get more time to develop, etc.
That’s an interesting observation. I like the analogy and it definitely helps you put things into focus.
Although, I should say the title lured me into thinking this was a rant! :)
That’s a fun comparison, but this is 417 words to make the point “don’t write bad code” :/
The point is a bit more subtle than “don’t write bad code”. It’s “make less mistakes than your competition”, which is actually a very different place to come from, and implies almost a sense of just keeping above the game, and that one might be able to get a lot out of focusing on a handful of things that are causing most of your mistakes, rather than just Not Writing Any Bad Code.
I would extend that to “make fewer basic mistakes than your competition.”
You’re more likely to kill your business by screwing up a database backup or password storage than you are to double your revenue with a 10% more efficient application.
Of course, what the basic mistakes are and how to avoid them is an exercise left to the reader!
That’s a good point - re-reading the article, I get what you and the author are saying here.
Anything that puts food on the table is a winners game. Constraints on previously stated “anything” apply (ethics, legality, etc).
Please read the post before you comment. Comments based only on the title, especially inserting a hyperbolic claim like starvation, don’t typically lead to very good conversations.
I actually did. I am just using a different single variable to model a winning vs losing game, not tennis points.
I don’t think the article claims otherwise?
It classifies the games into winners games where one needs to win by succeeding at more posotove feats than the competition, and losers games where one needs to win by making fewer mistakes.
If I am a professional programmer I score more positive points than the competition when the product sells (for some definition of sell).
If I am an amateur programmer, I may occasionally have the brilliant buzzer-beater, which I will remember for all my life (“once upon a time I wrote a 100 line SQL query”), but essentially I am not making a living out of it.
Hence, if it puts food on the table it is a winning game. That is my POV.
I have written a ton of stuff where I needed to negotiate the scope and then the thing that mattered most was having few enough problems, not doing something better — just to agreed spec is fine. It was paid work.
You can say that the outcome was winning; the point of the distinction the article makes is that it was winning by default, winning by not losing and getting to the completion.
I have also written code where you need to win by scoring positive achievements, it surely is a different activity, often with a slightly different feel. (Whether paid or purely for fun) Even if the avoid-negatives code has some positive achievements later allowing it to survive further evolution.
Thanks for explaining that – the title was so off-putting to me that I wouldn’t have read the article if you hadn’t explained the title.
For anybody on the fence, the article is actually fine.
This reminds me a little bit of the
-eticand-emicdistinction from (among other things) linguistics. The idea of studying something from the outside looking in (phonetics studies how different sounds are used to communicate across languages / “From outside” the context of a language) and from the inside looking out (phonemics studies how a particular language uses sounds to communicate).I think the rhyme here is found in the intrinsic/extrinsic distinction – a ‘losers’ game is won due to extrinsic (outside our control) factors, just like phonetics studies how sounds work separate from any particular implementation; and a ‘winners’ game is a game won due to intrinsic factors (just like phonemic studies the use of sound internal to a language).
I don’t know that there is much more relevance than the fact that these things seem similar, but it’s at least interesting enough to me to warrant a mention.
I’m really struggling with this “winner’s game” vs. “loser’s game” distinction. I don’t understand how the outcome of an amateur tennis game is “determined” by the loser hitting the ball into the net more times than the winner when you can just as easily say it was determined by the winner successfully hitting the ball in the court more times than the loser… Or why is a pro game determined by the winner acing the ball more times than the loser, and not by the loser failing to ace it as many times as the winner?
In a “losers game”, you win by never dropping below some threshold for performance.
In a “winners game”, you win by performing above some threshold.
For most software, the difference in value delivered between “buggy” and “works” is greater than the difference between “works” to “and it’s amazing”; thus, it’s a “losers game” in that the key is to consistently not ship bugs.
For tennis:
Amateurs win points by repeatedly returning shots until their opponent messes up. Dropping below ‘minimum acceptable’ means hitting the ball out when they could have hit it in (an ‘unforced error’).
In a pro game, ‘unforced errors’ are rare enough that the commentators spend a minute talking about them when they happen. The professionals simply don’t make that kind of mistake often, so points are won by actively creating a situation where the other player can’t respond (eg rapidly switching the ball to the opposite side of the court so their opponent can’t get across in time).
Yes! This is a much better explanation than most of the comments in this thread.
I think it’s an interesting perspective, but I disagree with the dichotomy. There’s only one game: make one of your opponent’s mistakes the last mistake of the game. I have heard this in chess (it’s not who makes mistakes, it’s who makes the last mistake), and when you compare to Fritz/Stockfish/&c, you can clearly see how much of a mistake each move was.
No, I disagree. Errors are often made by professionals, it’s just that you can’t perceive the error. Pretty much every time Serral wins a StarCraft final, and they interview him after hardly dropping a game, he says his play was “sloppy”. That’s (partly) why he’s the best. Obvious errors are seldom made, sure, but that doesn’t make 2 games.
Basically why I’m learning how to use Coq.
I’m genuinely interested to know how Coq brings you an winning edge in programming? Theorem proving seems orthogonal to programming to me
Coq keeps you from making mistakes. It prevents you from losing as many points.
Do you mean that you - and others - are using Coq as a general purpose programming language? Why not Idris?
It prevents you from making some kinds of mistakes, and it’s great, but it needs to come after a significant amount of fit-finding (prototypes, user research, etc), and the programmer needs the full context of the fit-finding (that is, they need to do it, not receive a report) from someone.
Most points are lost while deciding what to build.
Can someone clarify what would be the “less glamorous elements of our field”?
Probably the least glamorous part of programming I’ve come across is the large amount of “Reshape data from X format to Y format” that can happen in several layers in an enterprise software, and often has to be done by hand. The only way something like that becomes challenging is if there are some strong performance constraints. The sort of thing that ORMs try to reduce, for one.
Good point. A friend suggested that algorithms may fit this least glamorous group as well. I agree with that but it is like a doctor avoiding blood during surgery =)
I’m not sure I agree, to be honest. Algorithms work may not be externally glamorous, but it’s either heavy research (in the case of trying to build new ones), or well defined, but potentially tricky (in the case of implementing existing ones). Both cases cater to what is often a core engagement of software development for its practitioners (solving puzzles or passing a well-specified test-suite)
This is one of the key goals for activefacts - being able to combine a shared logical schema with descriptions of serialisations to generate the transforms between those formats. The foundation is there but it needs a good serialisations model.