The Economist this week writes about the increasing use of algorithms, for everything from book recommendations to running supply chains (Business by numbers, 13 Sep 2007). It suggests that algorithms are now pervasive.
The most powerful algorithms are those that do real-time optimization. They could help UPS recalibrate deliveries on the fly, and reorder airplane departure queues at airports to improve throughput. More down-to-earth applications include sophisticated calculations of consumer preference that end up predicting where to put biscuits on supermarket shelves.
If that’s true, the underlying fragility of algorithms is now pervasive. The fragility is not just due to the risk of software bugs, or vulnerability to hackers; it’s also a consequence of limitations on our ability to conceive of, implement, and manage very large complex systems.
The day-to-day use of these programs shows that they work very well almost all of the time. The occasional difficulty – from Facebook 3rd party plug-in applications breaking for mysterious reasons to the sub-prime mortgage meltdown – reminds us that the algorithmic underpinnings to our society are not foolproof.
In the same issue, the Economist reviews Ian Ayres’s book Super Crunchers: Why Thinking-by-Numbers Is the New Way to Be Smart about automated ddecision making (The death of expertise, 13 Sep 2007). According to their reading of his book, “The sheer quantity of data and the computer power now available make it possible for automated processes to surpass human experts in fields as diverse as rating wines, writing film dialogue and choosing titles for books.” Once computers can do a better job at diagnosing disease, what’s left for the doctor to do? Bank loan officers have already faced this question, and had to find a customer relations job. I used to worry about the employment implications; I still do, but now I also worry about relying on complex software systems.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
Friday, September 14, 2007
Sunday, September 09, 2007
Software: complex vs. complicated
Homer-Dixon’s The Ingenuity Gap helped me realize that perhaps the difference between software and more traditional engineering is that bridges (say) are complicated, while software is complex. I follow the distinction I’ve seen in the systems theory literature that complicated refers to something with many parts, whereas complex refers to unpredictable, emergent behavior. Something complicated may not be complex (e.g. a watch), and a complex system might not be complicated (e.g. a cellular automaton).
A large piece of code meets the criteria for a complex adaptive system: there are many, densely interconnected parts which affect the behavior of the whole in a non-linear way that cannot be simply understood by looking at the components in isolation. A code module can be tested and defined individually, but its behavior in the context of all the other components in a large piece of code can only be observed – and even then not truly understood – by observing the behavior of the whole. If software were linear and simply complicated, extensive testing wouldn’t be required after individually debugged modules are combined into a build.
Some have compared software to bridges while calling (properly) for better coding practices. Holding software development to the same standards as other facets of critical infrastructure is questionable, however, because a software program is to a bridge as the progress of a cocktail party is to a watch. Both parties and watches have a large number of components that can be characterized individually, but what happens at a given party can only be predicted in rough terms (it’s complex because of the human participants) while a watch’s behavior is deterministic (though it’s complicated).
This challenge in writing software is of the “intrinsically hard” kind. It is independent of human cognition because it catch you eventually, no matter how clever or dumb you are (once you’re at least smart enough to complex software systems at all).
Geek’s addendum: Definitions of complexity
Home-Dixon’s definition of complexity has six elements. (1) Complex systems are made up a large number of components (and are thus complicated, in the meaning above). (2) There is a dense web of causal connections between the parts, which leads to coupling and feedback. (3) The components are interdependent, i.e. removing a piece changes the function of the remainder. (I think this is actually more about resilience than complexity.) (4) Complex systems are open to being affected by events outside their boundaries. (5) They display synergy, i.e. the combined effect of changes to individual components differs in kind from the sum of the individual changes. (6) They exhibit non-linear behavior, in that a change in a system can produce an effect that disproportional to the cause.
Sutherland and Van den Heuvel (2002) analyze the case of enterprise applications built using distributed object technology. They point out that such systems have highly unpredictable, non-linear behavior where even minor occurrences might have major implications, and observe that recursively writing higher levels of language that are supported by lower level languages, as source of the power of computing, induces emergent behaviors. They cite Wegner (1995) as having shown that interactive systems are not Turing machines: “All interactions in these systems cannot be anticipated because behavior emerges from interaction of system components with the external environment. Such systems can never be fully tested, nor can they be fully specified.” They use Holland’s (1995) synthesis to show how enterprise application integration (EAI) can be understood as a complex adaptive system (CAS).
References
Sutherland, J. van den Heuvel, W.-J. (2002). "Enterprise application integration encounters complex adaptive systems: a business object perspective.” HICSS. Proceedings of the 35th Annual Hawaii International Conference on System Sciences, 2002.
Wegner, P (1995). “Interactive Foundations of Object-Based Programming.” IEEE Computer 28(10): 70-72, 1995.
Holland, J. H. (1995). Hidden order: how adaptation builds complexity. Reading, Mass., Addison-Wesley, 1995.
A large piece of code meets the criteria for a complex adaptive system: there are many, densely interconnected parts which affect the behavior of the whole in a non-linear way that cannot be simply understood by looking at the components in isolation. A code module can be tested and defined individually, but its behavior in the context of all the other components in a large piece of code can only be observed – and even then not truly understood – by observing the behavior of the whole. If software were linear and simply complicated, extensive testing wouldn’t be required after individually debugged modules are combined into a build.
Some have compared software to bridges while calling (properly) for better coding practices. Holding software development to the same standards as other facets of critical infrastructure is questionable, however, because a software program is to a bridge as the progress of a cocktail party is to a watch. Both parties and watches have a large number of components that can be characterized individually, but what happens at a given party can only be predicted in rough terms (it’s complex because of the human participants) while a watch’s behavior is deterministic (though it’s complicated).
This challenge in writing software is of the “intrinsically hard” kind. It is independent of human cognition because it catch you eventually, no matter how clever or dumb you are (once you’re at least smart enough to complex software systems at all).
Geek’s addendum: Definitions of complexity
Home-Dixon’s definition of complexity has six elements. (1) Complex systems are made up a large number of components (and are thus complicated, in the meaning above). (2) There is a dense web of causal connections between the parts, which leads to coupling and feedback. (3) The components are interdependent, i.e. removing a piece changes the function of the remainder. (I think this is actually more about resilience than complexity.) (4) Complex systems are open to being affected by events outside their boundaries. (5) They display synergy, i.e. the combined effect of changes to individual components differs in kind from the sum of the individual changes. (6) They exhibit non-linear behavior, in that a change in a system can produce an effect that disproportional to the cause.
Sutherland and Van den Heuvel (2002) analyze the case of enterprise applications built using distributed object technology. They point out that such systems have highly unpredictable, non-linear behavior where even minor occurrences might have major implications, and observe that recursively writing higher levels of language that are supported by lower level languages, as source of the power of computing, induces emergent behaviors. They cite Wegner (1995) as having shown that interactive systems are not Turing machines: “All interactions in these systems cannot be anticipated because behavior emerges from interaction of system components with the external environment. Such systems can never be fully tested, nor can they be fully specified.” They use Holland’s (1995) synthesis to show how enterprise application integration (EAI) can be understood as a complex adaptive system (CAS).
References
Sutherland, J. van den Heuvel, W.-J. (2002). "Enterprise application integration encounters complex adaptive systems: a business object perspective.” HICSS. Proceedings of the 35th Annual Hawaii International Conference on System Sciences, 2002.
Wegner, P (1995). “Interactive Foundations of Object-Based Programming.” IEEE Computer 28(10): 70-72, 1995.
Holland, J. H. (1995). Hidden order: how adaptation builds complexity. Reading, Mass., Addison-Wesley, 1995.
Friday, August 31, 2007
Limits to abstraction
Suze Woolf put me on to Grady Booch’s Handbook of Software Architecture, which aims to codify the architecture of a large collection of interesting software-intensive systems, presenting them in a manner that exposes their essential patterns, and that permits comparisons across domains and architectural styles.
Booch mentions in passing on the Welcome page that “abstraction is the primary way we as humans deal with complexity”. I don’t know if that’s true; it sounds plausible. It’s definitely true that software developers deal with complexity this way, creating a ladder of increasingly succinct languages that are ever further away from the nitty gritty of the machine. While there are huge benefits in productivity, there’s also a price to pay; as Scott Rosenberg puts it in Dreaming in Code, “It's not that [developers] wouldn't welcome taking another step up the abstraction ladder; but they fear that no matter how high they climb on that ladder, they will always have to run up and down it more than they'd like--and the taller it becomes, the longer the trip.”
The notion of “limits to abstraction” is another useful way to frame the hard intangibles problem.
These limits may be structural (abstraction may fail because of the properties of a problem, or the abstraction) or cognitive (it may fail because the thinker’s mind cannot process it). In The Law of Leaky Abstractions (2002), Joel Spolsky wrote (giving lots of great examples) “All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions. . . . One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to.”
There’s more for me to do here, digging into the literature on abstraction. Kit Fine’s book, The Limits of Abstraction (2002) could be useful, though it’s very technical – but at least there have been lots of reviews.
Booch mentions in passing on the Welcome page that “abstraction is the primary way we as humans deal with complexity”. I don’t know if that’s true; it sounds plausible. It’s definitely true that software developers deal with complexity this way, creating a ladder of increasingly succinct languages that are ever further away from the nitty gritty of the machine. While there are huge benefits in productivity, there’s also a price to pay; as Scott Rosenberg puts it in Dreaming in Code, “It's not that [developers] wouldn't welcome taking another step up the abstraction ladder; but they fear that no matter how high they climb on that ladder, they will always have to run up and down it more than they'd like--and the taller it becomes, the longer the trip.”
The notion of “limits to abstraction” is another useful way to frame the hard intangibles problem.
These limits may be structural (abstraction may fail because of the properties of a problem, or the abstraction) or cognitive (it may fail because the thinker’s mind cannot process it). In The Law of Leaky Abstractions (2002), Joel Spolsky wrote (giving lots of great examples) “All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions. . . . One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to.”
There’s more for me to do here, digging into the literature on abstraction. Kit Fine’s book, The Limits of Abstraction (2002) could be useful, though it’s very technical – but at least there have been lots of reviews.
Saturday, August 25, 2007
Programs as spaces
Paul Graham's essay Holding a Program in One’s Head describes how a good programmer immersed in their code holds it in their mind: "[Mathematicians] try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will."
The article’s mainly concerned with the organizational consequences of needing to "load the program into your head” in order to do good work. But I want to focus on the spatial metaphor. Thinking through a program by walking through the spaces in your head is an image I've heard other programmers use, and it reminds me of the memory methods described by Frances Yates in The Art of Memory. (While Graham does make reference to writing and reading, I don't think this is aural memory; his references to visualization seem more fundamental.)
I wonder about the kind of cognitive access a programmer has to their program once it’s loaded. Descriptions of walking through a building imply that moment-by-moment the programmer is only dealing with a subset of the problem, although the whole thing is readily available in long-term memory. He’s thinking about the contents of a particular room and how it connects with the other rooms, not conceptualizing the entire house and all its relationships at the same instant. I imagine this is necessarily the case, since short-term memory is limited. If true, this imposes limitation on the topology of the program, since the connections between different parts are localized and factorizable – when you walk out of the bedroom you don’t immediately find yourself in the foyer. Consequently, problems that can’t be broken down (or haven’t been broken down) into pieces with local interactions of sufficiently limited scope to be contained in short term memory will not be soluble.
Graham also has a great insight on what makes programming special: "One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that's what programs are: ideas." Not only are programming tasks not like fighting wars as Graham imagines them; they're not like manufacturing widgets either. The non-parallelizability of ideas implies their interconnections, and here we have the fundamental tension: ideas may be highly interlaced by their nature, but the nature of the brain limits the degree to which we can cope with their complexity.
The article’s mainly concerned with the organizational consequences of needing to "load the program into your head” in order to do good work. But I want to focus on the spatial metaphor. Thinking through a program by walking through the spaces in your head is an image I've heard other programmers use, and it reminds me of the memory methods described by Frances Yates in The Art of Memory. (While Graham does make reference to writing and reading, I don't think this is aural memory; his references to visualization seem more fundamental.)
I wonder about the kind of cognitive access a programmer has to their program once it’s loaded. Descriptions of walking through a building imply that moment-by-moment the programmer is only dealing with a subset of the problem, although the whole thing is readily available in long-term memory. He’s thinking about the contents of a particular room and how it connects with the other rooms, not conceptualizing the entire house and all its relationships at the same instant. I imagine this is necessarily the case, since short-term memory is limited. If true, this imposes limitation on the topology of the program, since the connections between different parts are localized and factorizable – when you walk out of the bedroom you don’t immediately find yourself in the foyer. Consequently, problems that can’t be broken down (or haven’t been broken down) into pieces with local interactions of sufficiently limited scope to be contained in short term memory will not be soluble.
Graham also has a great insight on what makes programming special: "One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that's what programs are: ideas." Not only are programming tasks not like fighting wars as Graham imagines them; they're not like manufacturing widgets either. The non-parallelizability of ideas implies their interconnections, and here we have the fundamental tension: ideas may be highly interlaced by their nature, but the nature of the brain limits the degree to which we can cope with their complexity.
Thursday, August 09, 2007
Factoid: 19 million programmers by 2010
According to Evans Data Corp, the global developer population will approach 19 million in 2010. (I found this via ZDNet's ITFacts blog; the EDC site requires registration to even see the press release.) That's quite a big number - the total population of Australia, for example.
Programming will not be a marginal activity, and any fundamental cognitive constraints on our ability to develop increasingly complex problems will be impossible to avoid.
A lot of the growth will come from new countries bringing programmers online: EDC forecasts that the developer population in APAC will grow by 83% increase from 2006 to 2010, compared to just a 15% increase in North America for the same period. This will keep the skill level high, since only very talented people will enter the population, rather than expanding the percentage of the programming population - and thus reducing average skill - in a given country.
Therefore, the qualititative problems of programming won't change much in the next 5-10 years. However, beyond that we may also face the issue of reducing innate skill levels of programmers.
Programming will not be a marginal activity, and any fundamental cognitive constraints on our ability to develop increasingly complex problems will be impossible to avoid.
A lot of the growth will come from new countries bringing programmers online: EDC forecasts that the developer population in APAC will grow by 83% increase from 2006 to 2010, compared to just a 15% increase in North America for the same period. This will keep the skill level high, since only very talented people will enter the population, rather than expanding the percentage of the programming population - and thus reducing average skill - in a given country.
Therefore, the qualititative problems of programming won't change much in the next 5-10 years. However, beyond that we may also face the issue of reducing innate skill levels of programmers.
Sunday, July 22, 2007
IT Project Success: Getting Better, but Big is still Bad
The biennial “Chaos Report” on IT project success from The Standish Group reports that the success/failure ratio flipped between 1994 and 2006. In 1994 the ratio for “flat failures” vs. “complete successes” was a depressing 31% vs. 16%; in 2006 it was a more encouraging 19% vs. 35%. (The work is reported in CIO; the Standish Group web site is remarkably sullen, and doesn’t seem to have any press releases, let alone publicly available recent data.)
On page 2 of the CIO story, the Standish CEO says: “Seventy-three percent of projects with labor cost of less than $750,000 succeed. . . . But only 3 percent of projects a with labor cost of over $10 million succeed. I would venture to say the 3 percent that succeed succeeded because they overestimated their budget, not because they were managed properly.” A $750,000 project is pretty tiny: six developers for six months, at $250,000/developer/year fully loaded. Even a $10 million project is 20 developers for two years.
This result matches received wisdom that large projects are more likely to fail, which I attribute at least in part to the cognitive challenge of wrapping one’s head around large problems.
What should one do about it? It implies that smaller projects are the only way to go – but what if one has ambitious goals? If it’s true that one can construct complex solutions out of many small, simple parts, everything’s fine. But I’m deeply suspicious of the “divide and conquer” or “linearization” assumption. There are many important problems that just can’t be broken up, from inverting a matrix to simulating non-linear systems.
This may be a cultural reality check: many ambitious goals may simply not be achievable. Humility may be the best way to ensure success. I doubt politicians and business executives want to hear this. Trying to fly too high brought Icarus down – exactly as his engineer-father Daedalus had warned.
And things may not get better: as technology progresses, the complexities of our systems will grow, and linear solutions become even less useful. As the interconnectedness and intangibility of society grows, we may have to become more humble, not more bold, because that will be the only way to get stuff done. It’s counter-intuitive that as technology progresses we need to become less, not more, ambitious, but that may be the way things work with the new intangibles.
NOTES
My thanks to Henry Yuen for referring this story.
I have some reservations about the Standish data. It’s proprietary, and there are academics who’ve questioned it for years. CIO provides some background on Chaos Report and its methods in an interview with the CEO; it also summarizes questions about their method. One has to wonder how the sample population has changed over the years. If the number of small projects in the sample has grown over time, then success reported above would increase simply because smaller projects fail less often, not because project management performance has improved.
On page 2 of the CIO story, the Standish CEO says: “Seventy-three percent of projects with labor cost of less than $750,000 succeed. . . . But only 3 percent of projects a with labor cost of over $10 million succeed. I would venture to say the 3 percent that succeed succeeded because they overestimated their budget, not because they were managed properly.” A $750,000 project is pretty tiny: six developers for six months, at $250,000/developer/year fully loaded. Even a $10 million project is 20 developers for two years.
This result matches received wisdom that large projects are more likely to fail, which I attribute at least in part to the cognitive challenge of wrapping one’s head around large problems.
What should one do about it? It implies that smaller projects are the only way to go – but what if one has ambitious goals? If it’s true that one can construct complex solutions out of many small, simple parts, everything’s fine. But I’m deeply suspicious of the “divide and conquer” or “linearization” assumption. There are many important problems that just can’t be broken up, from inverting a matrix to simulating non-linear systems.
This may be a cultural reality check: many ambitious goals may simply not be achievable. Humility may be the best way to ensure success. I doubt politicians and business executives want to hear this. Trying to fly too high brought Icarus down – exactly as his engineer-father Daedalus had warned.
And things may not get better: as technology progresses, the complexities of our systems will grow, and linear solutions become even less useful. As the interconnectedness and intangibility of society grows, we may have to become more humble, not more bold, because that will be the only way to get stuff done. It’s counter-intuitive that as technology progresses we need to become less, not more, ambitious, but that may be the way things work with the new intangibles.
NOTES
My thanks to Henry Yuen for referring this story.
I have some reservations about the Standish data. It’s proprietary, and there are academics who’ve questioned it for years. CIO provides some background on Chaos Report and its methods in an interview with the CEO; it also summarizes questions about their method. One has to wonder how the sample population has changed over the years. If the number of small projects in the sample has grown over time, then success reported above would increase simply because smaller projects fail less often, not because project management performance has improved.
Friday, July 06, 2007
Trading on News
Follow the money, if you want to know where the action is in AI (and most other things). Trading houses are buying tagged news feeds so that they can process them as input for algorithmic trading. That'sll have to be a pretty smart news reader.
The Economist story that reports this development contains these factoids:
Taken a step further, I can imagine the trading houses selling re-tagged news feeds back to Dow Jones and Reuters. Suitably anonimized, aggregated, and delayed to protect the individual movers, information on which news items triggered trades would be useful at second order. And then the news providers can sell the re-re-tagged feeds to the traders, who'll then sell back the re-re-re-tagged . . .
The Economist story that reports this development contains these factoids:
- Algorithmic trading accounts for a third of all share trades in America
- The Aite Group reckons it will make up more than half the share volumes and a fifth of options trades by 2010
- The new London Stock Exchange system catering to the growth of algorithmic trading cuts trading times down to ten milliseconds; on its first day, it processed up to 1,500 orders a second, compared with 600 using its previous system
Taken a step further, I can imagine the trading houses selling re-tagged news feeds back to Dow Jones and Reuters. Suitably anonimized, aggregated, and delayed to protect the individual movers, information on which news items triggered trades would be useful at second order. And then the news providers can sell the re-re-tagged feeds to the traders, who'll then sell back the re-re-re-tagged . . .
Thursday, June 07, 2007
Algo Trading
This week's New Scientist has a good review article on algorithmic trading (Robert Matthews, Gordon Gekko makes way for trading software, 30 May 2007).
Some excerpts:
"Investors have realised that the processing speed and sheer volume of trades a computer can make can help them to outwit the sharpest of dealers. . . . Ten years ago, algo-trading was almost non-existent, but according to a recent report by [Brad] Bailey, now at the Boston-based consulting firm Aite Group, one-third of all trading decisions in US markets are now made by machines. He predicts that by 2010 more than half will be done this way. At Deutsche Bank in London, over 70 per cent of a category of foreign currency trades, called "spot trades", are now carried out without human intervention every day."
"Silicon is taking over from carbon on Wall Street," says Bailey.
"Dave Cliff, a computer scientist at Southampton University and founder of Syritta, a UK-based consultancy firm that develops algo-trading software [has turned to genetic algorithms to manage the large number of parameters that have to be tweaked.] His new system takes an initial set of guesses about the optimal selection of market parameters, tests how well each parameter describes prevailing market conditions, and then "breeds" a new selection from these to arrive at a more effective set. This evolutionary cycle is repeated until optimum values for the parameters are reached which the algo then uses to trade with."
"Human traders can make up for the lack of data with instinct and experience, and hooking human instinct up to computing power is now at the leading edge of algo trading. The result is software that helps the trader come up with ideas for bagging some alpha, and tests those ideas in simulations to see if they'll fly. With so many variables, it's easy to make mistakes, but the computer can spot them before unleashing the algo upon the market."
Some excerpts:
"Investors have realised that the processing speed and sheer volume of trades a computer can make can help them to outwit the sharpest of dealers. . . . Ten years ago, algo-trading was almost non-existent, but according to a recent report by [Brad] Bailey, now at the Boston-based consulting firm Aite Group, one-third of all trading decisions in US markets are now made by machines. He predicts that by 2010 more than half will be done this way. At Deutsche Bank in London, over 70 per cent of a category of foreign currency trades, called "spot trades", are now carried out without human intervention every day."
"Silicon is taking over from carbon on Wall Street," says Bailey.
"Dave Cliff, a computer scientist at Southampton University and founder of Syritta, a UK-based consultancy firm that develops algo-trading software [has turned to genetic algorithms to manage the large number of parameters that have to be tweaked.] His new system takes an initial set of guesses about the optimal selection of market parameters, tests how well each parameter describes prevailing market conditions, and then "breeds" a new selection from these to arrive at a more effective set. This evolutionary cycle is repeated until optimum values for the parameters are reached which the algo then uses to trade with."
"Human traders can make up for the lack of data with instinct and experience, and hooking human instinct up to computing power is now at the leading edge of algo trading. The result is software that helps the trader come up with ideas for bagging some alpha, and tests those ideas in simulations to see if they'll fly. With so many variables, it's easy to make mistakes, but the computer can spot them before unleashing the algo upon the market."
Monday, December 26, 2005
Law as Code
Larry Lessig broke through to celebrity with his book Code and Other Laws of Cyberspace. He argues that the writers of software code create frames for behavior that can be as coercive as the law. I’ve started wondering about the reverse: treating laws as if they were software.
Our intuitions are grounded in how our brains use our bodies to interact with the physical world. Software confounds those intuitions because it’s doubly inexhaustible: it’s made up of ideas which can’t be “used up”, and the resulting product is itself perfectly copiable infinitely many times. Both the input and the output of manufacturing software is non-rivalrous, to use the economic jargon.
As we build a knowledge economy, we are surrounding ourselves with abstractions for which our body-based reasoning is ill-prepared. Examples beyond software include quantum mechanics, persistent exponential growth (eg Moore’s Law for silicon chips) and products built on pure probability (eg futures markets, and lotteries in general). Not all of this is novel, though. Laws, lotteries and logic have been around for millennia. However, people at large have not had to worry about their weirdness because they have only been parochial concerns to date. The pervasiveness of software can open our eyes – especially if we’re geeks and not wonks – to some of the curious properties of law.
One can think of the legal code as the operating system for a country. If the laws are the operating system, then contracts are the applications. There are many more contract lawyers that lobbyists, just as there are many more applications than operating systems.
The amount of code in a software program can be measured by counting the number of lines of source code, that is, the number of lines of human-readable instructions. Contemporary operating systems contain tens of millions of lines of code (Wikipedia cites line counts for some common operating systems).
I was surprised when I totaled up the number of lines in the US Code, the compendium of all the (federal) laws of the United States: about 5 million lines (spreadsheet). That’s about the same size as Windows NT or the Linux 2.6.0 kernel, at 4 million and 6 million lines of source code, respectively.
The “core development team” for the US Code is rather smaller than that for Windows or Linux, which are both said to be in the region of 8,000 people. The Washington DC legislature consists of 50 senators, 400-odd members of the House, and their legislative staff. If we assume a member to staff ratio of 1:3, that’s a team of 1,800 “developers”. Of course, one can’t forget the lobbyists, many of whom are lawyers who do the actual legislative drafting. Roberta Baskin, Executive Director of The Center for Public Integrity estimates that the federal lobbying industry employs about 14,000 people to influence the decisions of Congress, the White House, and officials at more than 200 federal agencies. Not all 14,000 are working on the US Code; many are working on agency regulations, which geeks might want to think of as the “middleware” of the legislative machine. (Note that I’ve ignored state law and local regulations in this approximation; it shouldn’t change the answer by more than about a factor of 2.) In all, the number of people writing the operating system for the United States is approximately the same size as the teams working on PC operating systems.
The analogy offers endless opportunities for harmless fun and mischievous comparisons.
Developers and lawyers quite similar: both write code, both worry about misplaced punctuation marks that could ruin everything, and both spend a lot of time on “edge cases”. Neither has ever seen a piece of code that they couldn’t do better, and both spend more time maintaining and tweaking legacy code than writing new stuff. However, it may take a little while for the maintenance of the US Code to be off-shored to India…
Legislation is infested with inconsistency; software tools that track links between code modules could help find discrepancies. S. remembers that her family was perplexed by what to do about an old tree in their garden. One regulation insisted that they cut it down, because it was old and rotten, and another insisted that it be protected, because it was just plain old. (They cut it down.) On the other hand, while tools can find buffer overflows in software, one needs the CBO to find budget overflows since legislation is code which is designed to run in the future, and have its worst side-effects when its drafters have happily retired to working as lobbyists.
One could see most of the activity in national and state capitals as the frantic “patching” of unintended side-effects in legal code. Tax lawyers seeking loopholes and hackers looking for trapdoors have similar goals – making the code do something it was not designed for. Unfortunately, it takes rather longer to patch the legal code than it does to issue a security update.
The judicial system is the “execution environment” for the code the makes up the code for a country. (In country as enamored of the death penalty as the United States, that computing term is more accurate than one might wish.) The courts figure out what the legal code actually does in practice. The function of the courts highlights a weakness in my analogy: laws are written in ordinary language with all its delightful vagueness, whereas computer code is written in mathematical symbols dressed up to look like language. In software, ambiguity is a bug; in law, it’s often a feature.
Our intuitions are grounded in how our brains use our bodies to interact with the physical world. Software confounds those intuitions because it’s doubly inexhaustible: it’s made up of ideas which can’t be “used up”, and the resulting product is itself perfectly copiable infinitely many times. Both the input and the output of manufacturing software is non-rivalrous, to use the economic jargon.
As we build a knowledge economy, we are surrounding ourselves with abstractions for which our body-based reasoning is ill-prepared. Examples beyond software include quantum mechanics, persistent exponential growth (eg Moore’s Law for silicon chips) and products built on pure probability (eg futures markets, and lotteries in general). Not all of this is novel, though. Laws, lotteries and logic have been around for millennia. However, people at large have not had to worry about their weirdness because they have only been parochial concerns to date. The pervasiveness of software can open our eyes – especially if we’re geeks and not wonks – to some of the curious properties of law.
One can think of the legal code as the operating system for a country. If the laws are the operating system, then contracts are the applications. There are many more contract lawyers that lobbyists, just as there are many more applications than operating systems.
The amount of code in a software program can be measured by counting the number of lines of source code, that is, the number of lines of human-readable instructions. Contemporary operating systems contain tens of millions of lines of code (Wikipedia cites line counts for some common operating systems).
I was surprised when I totaled up the number of lines in the US Code, the compendium of all the (federal) laws of the United States: about 5 million lines (spreadsheet). That’s about the same size as Windows NT or the Linux 2.6.0 kernel, at 4 million and 6 million lines of source code, respectively.
The “core development team” for the US Code is rather smaller than that for Windows or Linux, which are both said to be in the region of 8,000 people. The Washington DC legislature consists of 50 senators, 400-odd members of the House, and their legislative staff. If we assume a member to staff ratio of 1:3, that’s a team of 1,800 “developers”. Of course, one can’t forget the lobbyists, many of whom are lawyers who do the actual legislative drafting. Roberta Baskin, Executive Director of The Center for Public Integrity estimates that the federal lobbying industry employs about 14,000 people to influence the decisions of Congress, the White House, and officials at more than 200 federal agencies. Not all 14,000 are working on the US Code; many are working on agency regulations, which geeks might want to think of as the “middleware” of the legislative machine. (Note that I’ve ignored state law and local regulations in this approximation; it shouldn’t change the answer by more than about a factor of 2.) In all, the number of people writing the operating system for the United States is approximately the same size as the teams working on PC operating systems.
The analogy offers endless opportunities for harmless fun and mischievous comparisons.
Developers and lawyers quite similar: both write code, both worry about misplaced punctuation marks that could ruin everything, and both spend a lot of time on “edge cases”. Neither has ever seen a piece of code that they couldn’t do better, and both spend more time maintaining and tweaking legacy code than writing new stuff. However, it may take a little while for the maintenance of the US Code to be off-shored to India…
Legislation is infested with inconsistency; software tools that track links between code modules could help find discrepancies. S. remembers that her family was perplexed by what to do about an old tree in their garden. One regulation insisted that they cut it down, because it was old and rotten, and another insisted that it be protected, because it was just plain old. (They cut it down.) On the other hand, while tools can find buffer overflows in software, one needs the CBO to find budget overflows since legislation is code which is designed to run in the future, and have its worst side-effects when its drafters have happily retired to working as lobbyists.
One could see most of the activity in national and state capitals as the frantic “patching” of unintended side-effects in legal code. Tax lawyers seeking loopholes and hackers looking for trapdoors have similar goals – making the code do something it was not designed for. Unfortunately, it takes rather longer to patch the legal code than it does to issue a security update.
The judicial system is the “execution environment” for the code the makes up the code for a country. (In country as enamored of the death penalty as the United States, that computing term is more accurate than one might wish.) The courts figure out what the legal code actually does in practice. The function of the courts highlights a weakness in my analogy: laws are written in ordinary language with all its delightful vagueness, whereas computer code is written in mathematical symbols dressed up to look like language. In software, ambiguity is a bug; in law, it’s often a feature.
Subscribe to:
Posts (Atom)