The difference between programmers & attorneys

Computer programmers work with flowcharts to map out how various 'if-then' scenarios might unfold. After all, a program is nothing more than a complex set of conditional instructions (e.g. algorithms).  

Law is kind of the same thing. Laws can proscribe certain kinds of behavior, or limit it based upon conditions.  But lawyers don't use flowcharts much, so that's one big difference between them and programmers.  But, even if attorneys did, they'd create much different flowcharts. And that's were you begin to see the real separation between attorneys and programmers.

Let's use a real life example.  In June of 2005 the IRS passed some regulations, including one called Circular 230.  If you've ever gotten a routine email from a lawyer with boilerplate language that seems irrelevant and unnecessary then odds are you've been exposed to the Circular 230 problem.

Here's the problem.  IRS Circular 230 says, basically, that if an attorney wants to avoid any possible liability for giving people tax advice (that they then use to create a shady tax shelter) the attorney has to put in some boilerplate language.  Attorneys obviously want to avoid having a client say 'hey, you told me that it was okay in one of your emails.'  So when is it advisable to put boilerplate into an email?

Let's map out the problem—constructing a 'written' flowchart, if you will.

Here are the conditionals:  (1) the attorney's communication has to be 'written'; (2) and it has to contain tax advice; and (3) that advice has to be used, or possibly used, by the recipient to (a) avoid IRS penalties or (b) to promote some kind of tax-minimizing or tax-avoiding scheme.

Here's how a computer programmer would create an algorithm to determine when to use boilerplate: 

1.  Does the email contain any tax advice?
2.  Is it possible the tax advice will be used by the recipient to avoid IRS penalties or to promote a tax avoiding scheme?

OUTCOME: if answer to both (1) and (2) is YES, then insert boilerplate

And here's how a typical attorney would map it out:

1.  Am I sending an email to someone else?
OUTCOME: if answer to (1) is YES, then insert boilerplate.

So if you get an email from an attorney that has no discussion of tax issues, but which nevertheless contains the boilerplate, you'll now be able understand the logic.  Now, close your eyes, bow your head, and give thanks that attorneys don't design software.

Comments

[baltassoc]

To be fair to the typical attorney, the map is probably more like:

1. Might I ever send email that could be considered to have tax advice usable to avoid IRS penalties in some way I can't even conceive of, keeping in mind the bizarre and arbitrary tax-avoidance structures my buddy the tax attorney is always pulling out of his #$%@?2. Will the cost of me thinking through whether a piece of advice could ever possibly be considered tax advice (again, keeping in mind the completely bat&*%$ crazy reasoning in those three tax case opinions I stumbled across in my research in the XYZ project last year) every single time I send an email exceed the cost of automatically generating 230 footer as part of my signature file?

Outcome: if answer to both (1) and (2) is YES, then insert boilerplate in automatic footer.

[Loki]

Utterly brilliant Ernie! Great seeing y'all at dinner the other night.

[Cathy]

Oh but they DO effectively design software. Every time a risk-adverse attorney advises on Terms of Service and liability issues, they have a huge impact on the design and usability of software (particularly web applications).

See FaceBook TOS controversy for a current example. http://consumerist.com/5154745/facebook-clarifies-terms-of-service-we-do-not-own-your-stuff-forever

[SW]

Hey there,

You count a simple if-statement as an algorithm?

What seems more difficult to implement with your algorithm is how to get the answer to the question, "Does the email contain any tax advice?"

Most software and most programmers avoid such conditions.

Stephan

[Nostromo]

As a software developer, I have to tell you that flowcharts have been obsolete as a development method since the 1970s.

(That's not quite the same as saying that nobody is using them, of course. But I think it's safe to say that only a small minority of programmers, mostly older programmers or people who have become programmers without much formal education in computer science, are using them.)

[derf]

Given the propensity I've seen for coders to make something "multithreaded" by just throwing a big lock around every method in their object, they sound exactly like lawyers to me.

[Cletus]

So how then is it not misrepresentation on the part of the lawyer to offer tax advice for consideration and then give you a statement that relies on your own interpretation? If you hire and attorney to give you his legal opinion what have you paid for if you ultimately have to rely on your own opinion? How is your advice merchantable?

[Thorne]

I always get a kick out of it when someone in the firm's marketing department sends me an e-mail asking if I'm available for work, and then there's that bizarre boilerplate lingo at the end of it.

Asking me if I'm busy is giving me tax advice?

The other one I get a kick out of is this — "prior results do not guarantee a similar outcome." Isn't there a rule about singular/plural disagreements?