[dexen]

> The primary function of a legal department is to provide advice that prevents legally actionable mistakes. This advice does not have to be sane, or efficient, (...)

Strong disagreement. As a counterport, would you agree to the following: ``the primary function of a programming department is to crank out code. the code doesn't have to run predictably, nor be maintainable nor indeed have any business requirements. KLOC is the king.''?

When I'm programming privately in my spare time, my code doesn't need to run, be maintainable or useful or anything. But as long as I'm clocked in during office hours, my work should further company's goals, in harmony with other teams and projects. And just as much with legal departments: those should consider the overall effects of advice they give out. If not them, who else is to do such analysis -- some meta-legal department?

Been there just recently; an employment contract template prepared for my company by a lawyer was so one-sided and full of risks for potential employees, I stood up to the CEO and voiced against its proposed form. I've warned the CEO a lot of self-respecting hackers would rather give up offer than work on such conditions. The contract, while legally covering the company, would have detrimental effect on our ability to hire good hackers in the first place.

[jamesaguilar]

It seems like a lot of engineers, both here and elsewhere, have a very simplistic view of what other departments do. I've seen similar simplistic statements about design and management. I guess that's just part of human nature, to develop the view that only your work is complex or nuanced.

[brazzy]

It's not just work, and there's a name for it: http://en.wikipedia.org/wiki/Outgroup_homogeneity_bias

[anthonyb]

In this particular case though, there's not a lot of complexity or nuance, is there? It's a blanket "We own all your IP" clause in a contract.

[jamesaguilar]

Maybe . . . are you OK with the legal department assuming you are a lazy simpleton if you launch software with any bugs? Especially considering any misfeatures may have been implemented under management's direction?

[anthonyb]

I'm not sure that I see your point. Adding extra bits is more work for the legal team, and might lead to 'bugs', but a clause like this is going to lead to pissed off engineers who might leave.

To further mangle the analogy, what if I release bug free code that doesn't do what it's supposed to do?

[001sky]

Lawyers see a "mistake" and go for a landgrab. FB/Instagram TOS update was probably a similar dynamic. Legal likes to err on the side of over-reach, all other things equal.

[inerte]

But contracts itself are bound by city, state, and federal law, including civil, labor, IP, patent, etc...

Or you might get a bad lawyer or a favorable judge.

[anthonyb]

So? Contracts should be as close to your agreement as possible, and be within city/state/federal laws.

If your contract isn't accurate, it's like programming by hammering some shoddy crap together and letting the testers/users sort it out.

[zaidf]

the primary function of a programming department is to crank out code

OP didn't say the primary function of the legal department was to crank out legal language. He does say their job is to crank out advice that "prevents legally actionable mistakes".

Similarly, I think most developers at core are expected to output code that fulfill some communicated requirement.

[ProblemFactory]

This is a much better comparison.

Most programmers code to a "spec" - what they were asked to do. Only a small minority would voice their opinion if the spec is badly written or the product is not a good business idea.

[lsc]

>> The primary function of a legal department is to provide advice that prevents legally actionable mistakes. This advice does not have to be sane, or efficient, (...)

>Strong disagreement. As a counterport, would you agree to the following: ``the primary function of a programming department is to crank out code. the code doesn't have to run predictably, nor be maintainable nor indeed have any business requirements. KLOC is the king.''?

I don't see where you are getting KLOC; KLOC is rarely a metric that Programmers like. They'd choose readability, or (run-time) efficiency or something.

But yes; That's what you see. In both cases, really; I know last time I went to a lawyer for help with a AUP or privacy policy, I got something ridiculously one-sided that protected me, but would have been an absolute PR disaster to actually hand out as policy.

And yeah, I've seen programmers come up with solutions that were equally good from a purely technical perspective, but equally insane from the perspective of the whole business.

This is why managing a business is so difficult. You can't expect the lawyer to understand PR any more than you can expect your programmer to understand marketing. (I mean, sometimes you get lucky and find someone that is pretty good at both... those people are quite valuable, if you can find them.)

Actually, that's another discussion entirely. When you see the company you are working for (as a narrow specialist) doing something that is bad outside of your specialty, how hard do you try to change that? I mean, certainly, you should say "This isn't my specialty, but I think doing X is wrong, I think you should do Y" - the question then, is how hard do you fight for it. I mean, it is the person managing the company's job to choose specialists who are competent. At what point do you step out and say "Hey, you screwed it up" outside of your specialty?