6 ms·
The lesson, or at least the lesson I've learned from dealing with lawyers at companies big and small, is that lawyering is a practice in making sure nothing can
by jballanc 13y ago
The lesson, or at least the lesson I've learned from dealing with lawyers at companies big and small, is that lawyering is a practice in making sure nothing can possibly go wrong.
In a way, lawyers are the QA team for the legal world. They know that the shit hitting the fan can potentially be very expensive, so they will go to extreme lengths to prevent any possibility of that happening. But just like you cannot rely on your QA team to prioritize features and bug fixes (because, really, who's going to click those 15 buttons in that precise order with that precise timing to trigger that bug), you cannot rely on a lawyer to determine your business plan.
Lawyers fill the role that lawyers fill. If you're an engineer, then you have to fill the engineer role.
What is that role? My father is a mechanical engineer, and he explained to me very early on just what it means to be an engineer. You see, an engineer could design a bridge that doesn't collapse and lasts for thousands of years, but that's not the engineer's job. The job of an engineer is to take the cost of materials, the budget, the expected longevity of the bridge, the project schedule, the prevailing environmental and geological conditions of the siting, etc. and balance all of these different variables against each other to arrive at a solution.
If we're programmers, then we're saying that we can write down instructions in such a way that a computer can execute them and produce some output. If we're software engineers, then we're saying that we can balance features, schedule, bug fixes, test coverage, etc. and eventually ship it!
- Zuph 13y agoTold to me by one of my engineering mathematics professors: "Anyone can design a bridge that doesn't fall down. It takes an engineer to build one that only barely doesn't fall down."
- jnbiche 13y ago>The job of an engineer is to take the cost of materials, the budget, the expected longevity of the bridge, the project schedule, the prevailing environmental and geological conditions of the siting, etc. and balance all of these different variable against each other to arrive at a solution I'm not a lawyer, but I would assume that a good lawyer adopts an analogous process: they take the value of the contract, the prevailing legal conditions, the case history, etc., etc. and balance all these different variables against each other to arrive at a solution. I think the problem with many corporate lawyers is the same as with many corporate programmers working at large, traditional corporations: risk takers are heavily penalized, and those who make traditional, low-risk decisions are rewarded. You know, the whole "nobody ever got fired for using Java" bit. But lawyers working in private practice, or partners in firms with a lot of power, will presumably be willing to balance risk against reward, and try to optimize accordingly. Lawyers: please correct me if I'm assuming incorrectly here.
- ganeumann 13y agoWith lawyers, if everything goes perfectly then they just did their job. If anything goes wrong they're entirely blamed for it. Since they are paid by the hour, there is an explicit incentive to spend as much time as possible to make sure everything goes perfectly. Typical agency problem. It's up to the client to tell the lawyers when they are done. Now, the very very best lawyers, the ones who have a waiting list of clients, would prefer to spend less time on each contract. They want it done right and done fast so they can move on to the next thing. They fall outside this dynamic. But in any given field of corporate law there are only a handful of these. If you are at a startup, you are not using these lawyers (and don't need to). You need to be able to recognize the point at which your lawyer's comments pass the reasonable risk/reward tradeoff and ask them to put their pencils down and stop work.
- throwaway1979 13y agoPart of the situation is that the output of a lawyer cannot be measured clearly. The same is true for programmers but more people seem to be okay with shoddy code than with shoddy contracts. If the consequences of bad code were equally drastic as those of shoddy contracts, I'd imagine a lot more time being spent on code quality.
- tesseractive 13y agoActually, where the consequences of bad code are known to be drastic, a lot more time is spent on code quality. I worked on factory software at AMD for a while in the late 90s and early 2000s. The adage around there was that if the fab was down, it cost us a million dollars an hour. So we had a ton of testing, red tape, bureaucracy, and so on as part of change management. We did major upgrades and such on the 4th of July or during Christmas week, because those were the only times when the fab was down for more than an hour at a time (the hour was once a week at the weekly shift meeting for fab workers, IIRC). In preparation for those upgrades, we had a system set up as a duplicate of the (very expensive) production hardware and we actually rounded up the whole team and did dress rehearsals of the upgrade process, with go/no-go decision times built into the schedule based on timing how long it would take us to roll back the whole massive database from backup in time to ensure there would be no unscheduled downtime. We also had some folks who had come to the company from Lockheed. They helped upgrade our procedures, because as you might imagine, defense contractors are even more hardcore about all this than factory control systems. If you make a mistake in the embedded code inside a missile or airplane, things blow up (the wrong things!) and people die. This is more or less the opposite of a typical startup, where velocity is normally far more important than creating sufficient failsafes against any possible error.
- fixxer 13y agoWell, I mostly agree... but there are some very significant exceptions. Notably, I've dealt with in-house counsel from a certain Fortune 500 as part of my research and let me tell you this: they don't have a fucking clue what is going on. They just want to flex muscles for the sake thereof (or they think everything is "intellectual property", which is asinine). So, in this circumstance, they are a barrier to progress rather than a "QA" mechanism. I think in-house counsel is how things like "linked lists" and "document scanning" get patented. I hate them. Specific to the OP: I've also been sued a couple times (always got dismissed). Usually, you can tell if the client is the kind that is going to sue you for sport... learn to avoid them, unless you're desperate.
- sokoloff 13y agoActually, especially if you're desperate. Asshole counter-parties can smell weakness and if you are, they'll exploit it.
- fixxer 13y agoTrue. I meant desperate as in "food on the table". I grew up in the real estate industry. Software engineers don't experience anywhere near that amount of financial leverage. For most builders, every project is do or die; can't up and quit without it haunting your credit.
- sliverstorm 13y agohe explained to me very early on just what it means to be an engineer... This is precisely why engineering can be so much fun! Working with constraints and limitations on every side makes things interesting.
- hobs 13y agoI would say that is also produces the most beautiful results. The best art (and engineering) is that which is constrained, which then makes the creator explore how the boundaries of the rules fit in with what they need to accomplish.
- mathattack 13y agoYes - lawyers have just the downside. If something gets missed, blame the lawyer. As a result they get very aggressive on protection, and nitpicking. This behavior gets worse because they're incented on billable hours. They also don't share any upside. If a deal gets delayed by 2 months, they don't get hurt. The willingness to skip the lawyer is a set of risk taking that separates entrepreneurs. If there's a 1 in 100 chance that there will be a problem, then it's better to worry about all the 1 in 3 problems that can bring down the company. Now if you have 1000 projects going on, then you have to worry about the 1 in 100s...