Corner Cases, Code and Law
Jan. 18th, 2005 08:53 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
I've rewritten this three times and it's _still_ wrong. But I'm putting it up anyway, in the hope that criticism from you scurrilous lot will poitn out what exactly needs fixing
The idea that the problems of the world can be solved with a few well-placed rules is sadly all too common amongst geeks - their lives are usually full of rules - mathematical rules, physical rules, programming rules - simple instructions that produce beautifully complex results. Much as physicists tend to be convinced that the rules that make up the physical world can be reduced down to one aesthetically pleasing equation, a fair chunk of computer geeks seem to tend towards the idea that the world at large can be described by a few simple systems.
Fortunately, this tendency is usually kept to geeky areas, where it manifests as a belief that text interfaces are better than graphical ones, programs should be done right rather than soon, and that making changes to fit the customer's wishes is the root of all evil (rather than the purpose of their jobs).
It's when these tendencies branch out into real life that problems occur - when people start to believe that a simple set of instructions can lead to the perfect life, society or world. This tends to lead to such abominations as libertarianism and communism that start from simple principles ("No person shall directly harm another" and "We shall all work together") that seem seductively reasonable at first glance but have horrific results in the long run.
(For instance, a brief perusal of Slashdot will show a ridiculously large number of libertarian geeks declaiming that if only the government would get out of the way the world would run vastly better, and that the only thing keeping us back is the corruption of these civil servants.)
The reason for these unwanted results can be illuminated by what physicists call "The three-body problem". If you have two objects (or "bodies") floating in space then you can absolutely predict where they will both be at a future point. However, adding a third object makes the situation so complex that there is no known set of equations which will give you a general answer (in order to work out the position of planets at a future point astronomers carry out simulations instead). The amount of complexity increases
The IT expression for this is "corner cases" - these being the remarkably frustrating situations that occur when multiple sets of rules interact. The average programmer works by taking a problem apart into small enough pieces that each piece can be trivially solved, and then producing code that solves each piece. However, for anything other than pointlessly simple programs, situations occur where the code in one part of the system causes a problem for some other part of the system - the corner where the two systems 'intersect' with each other causes the system to either fail catastrophically or produce an unexpected result (which is even worse!).
The traditional way to deal with these corner cases is to 'patch' them - i.e. to write a new bit of code which works around the situation that causes the problem. There are two problems here - (1) finding all of the places where these corner cases occur and (2) each patch is a new piece of code, and therefore jut as likely to cause a new corner case as any old piece of code.
Over the lifespan of a piece of software more and more patches are applied as new corner cases are found, until eventually the events that can still cause problems are so rare as to either be negligible or so complex as to make them untraceable. Large numbers of systems allow superusers to override their normal working and edit data manually in order to deal with the occasional situation which is outwith expectations.
Now, these situations are annoying enough when dealing with code (which is, after all, binary and logical), but when dealing with real life situations they become many orders of magnitude more complicated. If you think of legal systems, these are made up of laws, each of which is designed to cause a certain effect. Hwoever, not only are they dealing with individual cases that are remarkably complex, but whenever a patch is applied to a law (in order to fix an unwanted result of it) the patch itself tends to have unintended results.
This gets particularly bad in the areas of tax and finance, where finding a corner case (or loophole) can net millions for a company. The government constantly patches the laws until they become so unwieldy that the average _honest_ business can't cope, and then attempts to rewrite them in a more basic form, while still taking into account all of the corner cases taken into account by the previous revision of the law. This slow swinging from simple law to complex and back again is a consequence of the clash between the need to both cover all situations without strangling people in complex regulations.
This is remarkably similar to the way that a new coder will take one look at a horrifically complex system, scream about its unnecessary hackery and unclean code and demand that it be rewritten - claiming that it can be made much simpler and much easier to code, in a tiny fraction of the original time. As any experienced coder will tell you, by the time these rewrite projects are complete (if they ever reach that stage) they are inevitably vastly over schedule/budget and full of exactly the kind of horrible stitching that they were complaining about in the first place.
The answer to this problem (in law) is exactly the same as it is when dealing with computer systems - allowing trusted superusers to decide what the answer _should_ have been and making sure that the final result is in accordance with that. We call these people 'judges'. In addition to making sure that the rules and procedures are followed, they are also assumed to have a very high working knowledge of not just how the law is supposed to work, but how it actually works, what kind of errors tend to occur, how to work around them, and what the best outcome is.
Very few people would want to live in a purely rule-driven society - there will always be loopholes, corner-cases and gaps in the logic. At some level people must be trusted to use judgement. Not trusted completely, obviously - there must be transparency and oversight, to ensure that power doesn't go to their heads - but trusted to know how to deal with the world better than any rule-driven system possibly can.
The idea that the problems of the world can be solved with a few well-placed rules is sadly all too common amongst geeks - their lives are usually full of rules - mathematical rules, physical rules, programming rules - simple instructions that produce beautifully complex results. Much as physicists tend to be convinced that the rules that make up the physical world can be reduced down to one aesthetically pleasing equation, a fair chunk of computer geeks seem to tend towards the idea that the world at large can be described by a few simple systems.
Fortunately, this tendency is usually kept to geeky areas, where it manifests as a belief that text interfaces are better than graphical ones, programs should be done right rather than soon, and that making changes to fit the customer's wishes is the root of all evil (rather than the purpose of their jobs).
It's when these tendencies branch out into real life that problems occur - when people start to believe that a simple set of instructions can lead to the perfect life, society or world. This tends to lead to such abominations as libertarianism and communism that start from simple principles ("No person shall directly harm another" and "We shall all work together") that seem seductively reasonable at first glance but have horrific results in the long run.
(For instance, a brief perusal of Slashdot will show a ridiculously large number of libertarian geeks declaiming that if only the government would get out of the way the world would run vastly better, and that the only thing keeping us back is the corruption of these civil servants.)
The reason for these unwanted results can be illuminated by what physicists call "The three-body problem". If you have two objects (or "bodies") floating in space then you can absolutely predict where they will both be at a future point. However, adding a third object makes the situation so complex that there is no known set of equations which will give you a general answer (in order to work out the position of planets at a future point astronomers carry out simulations instead). The amount of complexity increases
The IT expression for this is "corner cases" - these being the remarkably frustrating situations that occur when multiple sets of rules interact. The average programmer works by taking a problem apart into small enough pieces that each piece can be trivially solved, and then producing code that solves each piece. However, for anything other than pointlessly simple programs, situations occur where the code in one part of the system causes a problem for some other part of the system - the corner where the two systems 'intersect' with each other causes the system to either fail catastrophically or produce an unexpected result (which is even worse!).
The traditional way to deal with these corner cases is to 'patch' them - i.e. to write a new bit of code which works around the situation that causes the problem. There are two problems here - (1) finding all of the places where these corner cases occur and (2) each patch is a new piece of code, and therefore jut as likely to cause a new corner case as any old piece of code.
Over the lifespan of a piece of software more and more patches are applied as new corner cases are found, until eventually the events that can still cause problems are so rare as to either be negligible or so complex as to make them untraceable. Large numbers of systems allow superusers to override their normal working and edit data manually in order to deal with the occasional situation which is outwith expectations.
Now, these situations are annoying enough when dealing with code (which is, after all, binary and logical), but when dealing with real life situations they become many orders of magnitude more complicated. If you think of legal systems, these are made up of laws, each of which is designed to cause a certain effect. Hwoever, not only are they dealing with individual cases that are remarkably complex, but whenever a patch is applied to a law (in order to fix an unwanted result of it) the patch itself tends to have unintended results.
This gets particularly bad in the areas of tax and finance, where finding a corner case (or loophole) can net millions for a company. The government constantly patches the laws until they become so unwieldy that the average _honest_ business can't cope, and then attempts to rewrite them in a more basic form, while still taking into account all of the corner cases taken into account by the previous revision of the law. This slow swinging from simple law to complex and back again is a consequence of the clash between the need to both cover all situations without strangling people in complex regulations.
This is remarkably similar to the way that a new coder will take one look at a horrifically complex system, scream about its unnecessary hackery and unclean code and demand that it be rewritten - claiming that it can be made much simpler and much easier to code, in a tiny fraction of the original time. As any experienced coder will tell you, by the time these rewrite projects are complete (if they ever reach that stage) they are inevitably vastly over schedule/budget and full of exactly the kind of horrible stitching that they were complaining about in the first place.
The answer to this problem (in law) is exactly the same as it is when dealing with computer systems - allowing trusted superusers to decide what the answer _should_ have been and making sure that the final result is in accordance with that. We call these people 'judges'. In addition to making sure that the rules and procedures are followed, they are also assumed to have a very high working knowledge of not just how the law is supposed to work, but how it actually works, what kind of errors tend to occur, how to work around them, and what the best outcome is.
Very few people would want to live in a purely rule-driven society - there will always be loopholes, corner-cases and gaps in the logic. At some level people must be trusted to use judgement. Not trusted completely, obviously - there must be transparency and oversight, to ensure that power doesn't go to their heads - but trusted to know how to deal with the world better than any rule-driven system possibly can.
no subject
Date: 2005-01-18 09:04 pm (UTC)I also firmly believe that similar beliefs are responsible for so many geneticists being enraptured by the idea of evolutionary psychology aka genetic determinism. Essentially, these want human behavior to be governed by a few simple rules and so the look for these rules in genetics. Often, they concoct ill-designed studies because they are so certain that these simple rules must exist.
no subject
Date: 2005-01-18 09:10 pm (UTC)Stalins attempt to train people out of left-handedness being one particularly amusing example of this.
no subject
Date: 2005-01-19 08:34 am (UTC)I wouldn't say that the situation described above is inevitable. If the skill and understanding of the re-writer exceeds the skill an understanding of the original author (and these two may be the same person at different points in time), then the rewrite often succeeds, both in being quicker than trying to understand and patch the horrid code, and in the result being less buggy and easier to maintain (patch!) in future.
The real skill comes in knowing early enough when and if to go for the rewrite and when to dig into understanding the existing code.
Just to clarify - it can and does happen the way you describe (especially as it's also an ideal place for scope creep to rear its ugly head), but it doesn't always.
This experienced coder has had a lot of success with saying "it's quicker to rewrite", and doing so. Far more success than 'failure'.
no subject
Date: 2005-01-19 09:01 am (UTC)Smaller systems tend to get rewritten because they were really badly written, and rewriting can be done by one person in a reasonable time.
Large ones should only be touched if there's been a signifcant change in either technology or the purpose of the system - i.e. if the old system was based on a heirarchical database, not a relational one or if the laws governing income tax have been simplified and the previous laws were built into the assumptions of the computer system.
no subject
Date: 2005-01-19 01:29 pm (UTC)I've never been a fan of rewrites for the sake of it, or becaue we have a new whizzy technology - if your ancient Cobol payroll program using tape drives to store data (my first job) still fulfills the requirements of processing your payroll, and your users can still do all they need to by way of admin/entry then there is absolutely no need to change it at all. (helps to write flexibly with ease of expansion always in mind)
no subject
Date: 2005-01-19 07:28 pm (UTC)I'm not sure that this is the case. Whilst there is a search to unify physical forces into a single Theory of Everything, I think little of practical prediction will come of it. Since physicists have had great success in predicting the universe using a whole slew of different equations for different situations, any unifying theory will have to reduce to the different equations in each situation.
I'm not sure whether this metaphor works, but here goes. Even though we can distill a liquid, it doesn't mean the original liquid has no use; just because we can make whisky, doesn't mean beer is obsolete. The point is that each has its specific effects, the times and places where each is appropriate and, dare I say, its specific gravity.
no subject
Date: 2005-01-22 05:23 am (UTC)There does seem to be a tendency in our scientists to jump to somewhat strange conclusions, investing more complexity in the rules than really makes sense. Quantum mechanics and superstring theory spring to mind (see my blather here on one aspect of the former). The universe is complex, but the rules upon which it is based aren't (or haven't really been so far).
no subject
Date: 2005-01-22 11:11 am (UTC)Which is like saying "any rewrite of the laws of motion will have to reduce to Newtonian physics anyway, so finding the antecedents won't provide anything new"
It certainly might not. But then it could suddenly illuminate things in a whole new way.