Nested ternaries, ungodly amounts of repetition, ZERO tests, hardcoded sensitive info... this code wouldn't pass code review anywhere. I don't care when it was written, any day it is used to send people to jail it should be the best possible code humans can write. And it is so far from that.
But... start ups still pay engineers salaries that dwarf teachers, retail, and many other industries. Should people in those industries not have kids? Are they being irresponsible by not making 6 figures?
If you adopt micro-services in earnest, a challenge you face is how to ensure that the right set of services can communicate (and only communicate with) the right other set of services. In a large organization, it's not unrealistic to have hundreds of services, and not all of them are fully trusted (some may be run by vendors, etc).
What's more, these things are being constantly deployed to a wide variety of environments. Some may be on cloud VMs (or a dynamically scaled cluster of VMs), some on bare metal, some in orchestrators like Kubernetes. Some will run on networks that the organization maintains, some may be maintained by a DC or cloud provider.
Historically the answer to securing this communication has been to use L3 network segmentation with strict rules to decide who can send packets to who. But, particularly in an increasingly heterogenous and dynamic environment it's very difficult to do this reliably and quickly. Networks are also a pretty crude authorization system - it implies that just because you can reach an endpoint that you are authorized to use it, which isn't necessarily true in practice. Some of the other benefits of Istio - like system-wide circuit breaking and flow control are also difficult to do purely at the network layer.
If you're interested in this, I'd encourage you to check out https://spiffe.io/about which has some more detailed thoughts on the limitations of the L3 micro-segmentation approach and how it can be solved.
As a former teacher, who ran a programming club at a middle school and taught an advanced 8th-grade math class included programming, I have some perspective on this. I would say, be wary of "fundamentals" and "doing things the right way." Teaching a 10 yo something optional needs to be fun, or else it won't happen.
The author of this article nails it: there's nothing quite as motivating as adding "Poop" to the title of a real web page. Also, you can Inspect Element and get what is effectively an IDE. Is JavaScript the best language? No, it's inconsistent and confusing. But, so is English, and a lot of people learn English first - because it is practical to do so.
Another option that can be useful are Google Sheets. If they are a certain type of kid, they might like logging all of their toys in a spreadsheet and finding the total of the toys and making charts. Of course, most kids will find this boring... but you can also use Google Scripts to do something like scrape a subreddit and store it in Drive [1], which could be fun.
However, why not start with Scratch, or Snap! [2]? They are powerful enough (especially Snap!, I think you can define new data types in it...) and so much less intimidating.
> Teaching a 10 yo something optional needs to be fun, or else it won't happen.
That matches my intuition. But the word "fun" brought back to my mind this epigram by Alan Perlis:
> It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail and learning to be self-critical?
Unless I have completely misunderstood this epigram, I think the point is that programming, when done well, is not fun; it's work. So maybe if we try to make programming fun so we can teach it to a child, we're setting bad expectations for what it will be like if they pursue it seriously.
So I guess that means that when teaching programming to someone of any age, we do need to focus on fundamentals and the things that Perlis mentions in that epigram. Then, if a 10-year-old kid loses interest, we should just let it go.
Makes me wonder if I and other self-taught programmers of my generation (I was born in 1980) built our careers on a bad foundation. I started learning to program in BASIC on my family's home computer when I was 8 years old, because when just dabbling in BASIC, it was fun. Even tinkering with assembly language was fun. But the important thing to note is that as far as I can recall, I produced only one truly worthwhile program as a pre-teen, and that was one that a relative asked me to write. And that was a serious project, not a diversion (AFAIK, the latter is the definition of fun, as is apparent from some languages like Spanish).
As for Perlis's jab at "modern education", I suppose the take-away is that we need to teach kids early that life isn't fun, rather than trying to make everything fun for them.
A family member is a lawyer in the Worker's Comp, SS, and Family Law space. THE software for lawyers in this space is called A1 Law. It solves a lot of real problems lawyers in that space have (form letter generation, calendar integration, case management)... but it's so slow to use new technologies. They advertise PalmOS integration. My family member has to have their own server in a closet running the server version of this so his team can use it! He has no idea how to manage a server, it's absurd that he has to.
Everyone I know in law is dissatisfied with every part of their tech stack. If someone could come up with an integrated SaaS solution, and be SUPER careful about compliance... they would be printing money.
I would strongly encourage people to think twice about trying to sell software to lawyers.
It's a Sisyphean task. They are, as a rule, extremely anti-technology and conservative. At a previous startup, we had built software which was saving customers many hours a week—yet it was still an uphill battle to get paying approval.
If even after all the warnings in this thread you really want to build legal software, focus on disrupting lawyers instead of selling to them.
In general, law and media are two of the worst fields for technology.
I worked in a tech department of a rather large law services organization. There was a desire to maintain certain inefficiencies so that more hours could be billed to clients. If it could be done in 25% of the time, that's 75% less they could bill clients for 'attorney time spent.'
See how well pitching 'do it faster and make less' goes over.
Can't they still bill whatever they want? If 10 hours of proofreading, form filling, photocopying, and filing would be billed for $1500 (10 hours x $150 an hour), couldn't they still charge $1500 if the software took 80 milliseconds to do the same job?
Oh, the clients expect an itemized bill? Simple, the above charges would be "10 legal intern equivalent hours @ $150/hour". If a client questions it, the lawyer can explain that they are now using a very expensive piece of software instead of interns and attorneys for certain tasks, but felt it was an ethical obligation to quote the cost in a human understandable way. Turn the arbitrary pricing into a positive!
And of course your software should be able to quote all its tasks in these legal intern equivalent hours. This also leaves the lawyers hands clean since they can say that the software came up with hourly figure, not them.
I think the problem is one of mindset. From my perspective, even looking at accountants. Their industry and the clients they serve think that they are selling their "time", and not a service by itself. So, reducing the time it takes the lawyer/accountant to do something simply means less time being billed. It does not mean that they can now charge "more" for the time, as the cost per unit of that expert's time appears to be fixed by some other mechanism. Like seniority and years of experience, and not efficiency.
Perhaps bringing it back to a development perspective might shine some more light on it for us. Imagine you're a freelance developer and you've now developed (or bought) a fancy piece of software that allows you to do plenty of code-generation and reduce the amount of menial database layer code that needs to be written. You're now say 1.5x more efficient at delivering a product. What are you to do then? I doubt many clients would agree to a once-off fee for usage of your fancy code generation tool, even if you phrase it as saving "4 intern developer hours", and charge appropriately. There is also probably a cap on the hourly rate they're willing to pay you. Either that, or you change to a per-deliverable or product pricing model.
Exactly. The legal industry predominantly uses hourly billing and making up "equivalent hours" would be extremely unethical.
It's part of why I encourage everyone I know (particularly developers) to switch from hourly to fixed-price billing. Any efficiencies you gain should belong to you, not the customer. (There's also the fact that I find a lot more people are willing to pay $10k for X than $250/hr for 40 hours.)
The problem with fixed price as a developer is that rarely are requirements exactly understood or detailed enough to actually be able to bid the job. "Export to PDF" ok.. no problem -- that then turns into: "can you add page numbers? Can you support A4 - and US letter sizes?" And you have scope creep-- one more little thing isn't reasonable to say no to, however it quickly becomes a death by a thousand paper cuts. Ok, so now you price in that enevitable scope creep, so now your price is much higher. "$5000 to export to PDF? That's crazy!" -- yes but I am anticipating the fact that you don't know exactly what you want. "But we do, we made it clear!"
You see how that goes. Project pricing leads to a guessing game. Billing hourly is fair for everyone, at least in software. If I am more efficient, I pass that onto the customer. I don't 'lose' money -- it usually results in more work.
Imagine charging $80 for some corn because I want to make the same money as if I had guys hand-picking and hand seeding and doing the entire farming process without machines. That corn only cost me $0.10 to produce but I am charging a price as if I didn't have modern efficiencies. I would sell a lot less corn and actually profit less due to both competition and price elasticity. People would look for alternatives to corn.
In software, not passing on efficiencies means that there would actually be a smaller market for software development. Imagine how bad the market would be for us if we wrote everything in assembly. A simple web site might cost $100m and there'd be exactly 5 people in the world building websites.
I did some fixed price work this summer for a project where I thought the scope was unusually well understood by both sides. About 3 months, 60k USD if done by a fixed deadline (yes - fixed scope, fixed price, fixed deadline!) and as far as I was concerned from the original spec I had it done within about 6 weeks.
Of course, I spent the rest of the project time politely asking the customer to sign it off and doing the odd freebie to try and keep them happy but mostly at home, not working and not wanting to take anything else on in case they turned round and said I'd screwed up somewhere massively.
Perhaps unrelated, but I still haven't been paid for all of it either. Still, if I do eventually get paid it all it will have worked out better than charging per hour.
That's why Scope of Work documents exist: to protect against scope creep.
If a customer demands additional features, you prepare a Change Order and say, "OK, here is how long it will take and how much extra it will cost."
After a while they learn discipline and stop asking for changes half-way (or more) into the project.
Here is another perspective: the vast majority of features I've build as part of Change Orders rarely, if ever, got used. Granted, I make sure all relevant stakeholders are involved in the creation of the initial Scope of Work. That way, there are no late-comers who demand changes/additions.
The way I think about it is that general efficiency gains flow to the customer, while my unique efficiency gains are mine. So if it might take the average developer 100 hours to finish something but I can do it in 80, then I should charge as though it took 100.
The problem with hourly billing is it very poorly aligns incentives. It actually discourages efficiency because the easiest way for me to make more money is to take longer.
Also, psychologically, most clients are not comfortable with the vast differences in appropriate pay between developers. Even in the worst case (where scope was poorly defined and/or I estimated poorly), I'm making more now than I ever did with hourly billing.
If you had a monopoly on modern farming, it would absolutely make sense to charge $40 for corn. You'd soak up all the demand (since you're undercutting the $80 hand-harvesters) while still having massive profit margins.
Getting good at scoping is difficult but by no means impossible.
I chose my accountant because I could record my spendings online. He can just generate my yearly reports on one click in his backend, which he bills €80 for, "per click". He gives better advice because he has more customers, thanks to this efficiency, he doesn't spend time on mundane stuff and spends most his time meeting customers like me who present him various problems to solve, therefore he's more accoustomed to problem-solving.
Comapanies in my coworking space switch one after one. One has gone from a ~6500€ yearly bill to ~3500€ (3 employees), while improving reportability.
Non-industrialized accountants are just as necessary as human cashiers: Not. Lawyers are a bit harder to industrialize.
Not saying something like this would be impossible, just saying what I saw. However, the line of reasoning could be slippery. For example, they could say "1000 lawyer hours at X dollars an hour." When questioned, the company says "we could of had them trace all the documents with a pen to copy them by hand. Instead we used a photocopier, so we're billing you for the awesome technology." Seems like it'd be a hard sell and possibly unethical (in another way than it already is). I do think things might be able to be changed in terms of mentality, though.
I think contracts (between law firms and their clients) use hours worked because they don't know upfront how complicated cases will be, how long it will take etc. It's not just for "understandable pricing". Your "bill whatever they want" suggestion is basically saying that at the end, the law firm can quote whatever price they want, and the client agrees up front to pay that.
Actually, I'm a lawyer and a product owner at a big accounting firm, so I'm pretty well positioned to discuss this topic. I have half a dozen solid startup ideas that I'm tempted to take and start running with right now. Documentation management alone is in desperate need of innovation. I build toy apps in my spare time that cut thousands of dollars of charge hours young associates waste on bullshit tasks, just within my one small practice group. The whole legal software industry is a joke.
But here's the real problem for anyone looking to innovate in that space: the customers. Lawyers are as a rule anti-technology, slow to adapt new techniques, and set in their ways. Worse yet, they just bill their clients for their shitty software like Lexis or WestLaw, so they aren't even personally motivated to reduce costs.
> cut thousands of dollars of charge hours young associates waste on bullshit tasks
Doesn't this take money away from your firm? It is only when firms are competing on cost, time or client recognized quality that they will institute better workflows via software.
Depends, there are billable hours e.g. time spent with customers and non-billable hours e.g. administrative tasks not specific to any customer such as payroll, transfer of knowledge between work colleagues. So by targeting reduction of non-billable hours, you would have a compelling reason to sell to firms who bill by time.
That's pretty much true in general. Our fees are dictated more by the market than our actual costs. So if we were billing fewer hours, we'd just raise the hourly billing rate for our associates.
From our perspective in the national standards group, we would actually want our associates to just spend more time on value added activities. Instead of wasting time organizing PDFs of exhibits and monkeying around in spreadsheets, we want to them evaluating the relevant legal and technical tax issues. So it's not precisely cost control that is the primary concern, but quality assurance.
No, because we are in fact competing on cost and client-recognized quality, and to a lesser extent time. Plus our fees are driven more by the market than by our actual costs, so if we billed fewer hours, we would simply bill at a higher rate to reach the same expected fee while still maintaining our position in the marketplace. Or if we could reduce our fee, we might be able to win more market share.
The pejorative term in the industry for padding billing with useless busy work is "fee justification," which really shouldn't ever be necessary. Especially in my practice area, because there's always more work that can be done to flesh out our deliverables, which in turn makes them more effective for convincing the IRS (or state equivalent) or an appeals judge. When I say I've cut thousands of dollars of charge hours, we didn't simply stop charging those hours, we allocated them to more useful, value added activities.
Right now, staff spend far too much time inefficiently manipulating data in Excel, manually organizing exhibits, and a variety of other mundane, low cognitive effort tasks (I can't really specify what kinds because that would essentially doxx me). They feel productive, they look productive, and they meet their charge hour goals. And it allows them to procrastinate on the more mentally taxing work, like evaluating the relevant legal and technical tax issues, which in turn detracts from the quality of our service. Our clients aren't paying us to be extra-expensive outsourced spreadsheet monkeys. They're paying us to eliminate uncertainty about complicated legal and tax issues. So freeing up engagement budget and the staff's mental bandwidth to focus on the high value added cognitive services is tremendously useful in improving quality.
And in terms of time, we compete on that in some cases where there's an audit, exam, or appeal deadline and the client came to us late in the game. But that's an edge case and relatively rare. Certainly having a reputation for being quick, efficient, and timely wouldn't hurt our market position, though.
This is great news! I did a PoC for a document search system for discovery, OCR and full-text search. We deemed it too hard of a sell for law firms. Maybe the landscape is changing.
A lawyer friend of mine told me his firm doesn't use software to check all the "hereafter referred to" are bound to their template and vice-versa. They instead have to print the document and go through it with a highlighter.
The firm charges their clients on an hourly basis, so they don't really have an incentive to be more efficient.
I feel like charging on an hourly basis is a common pattern in many industries that opens the doors to competition from startups with different pricing structures...as long as the startup can do everything in a manner compliant with the existing industry.
Logojoy, for instance, is an example of a service that supplants human labor with a single "good-enough" deliverable at a low price, and does so in a fraction of the amount of time. I imagine this would be much more difficult in legal settings, but LegalZoom seems to be alive and kicking, so it must be possible.
To your second paragraph, I would add that it's hard for customers (and lawyers) to figure out what is "good-enough" in the legal setting. I'm a lawyer and there's a lot of stuff you can find on the internet that I personally think is good enough (I would use it in my personal affairs because the risk of the missing edge cases being an actual problem is slim) but I wouldn't be comfortable recommending it as a solution to a client because those missing edge cases are a real malpractice risk.
In the case of a logo, good enough is whatever the client thinks is good enough. In the case of a lot of legal solutions, good enough is often a murky risk/reward calculation based on legal concepts the client may not understand completely.
I still think there's enormous room for improvement, both in helping clients understand the concepts and the risks they're taking, and also in providing better automated solutions.
I think it could be done, especially if you could gather enough information to show people the likelihood of certain problems happening given their circumstances. The biggest problem is that without software to do the heavy lifting, you're spending so much time talking to the client that you might as well be their lawyer. And then even if you save them money, their "real" attorney might argue against your advice or retrace all your steps at an hourly rate.
I'm sure that there are lots of legal consulting companies that do this for people and entities that consume lots of legal services but the real trick is providing it profitably to "unsophisticated" people doing a one time thing.
> I feel like charging on an hourly basis is a common pattern in many industries that opens the doors to competition from startups with different pricing structures...as long as the startup can do everything in a manner compliant with the existing industry.
That last step's a real doozy, though. Startups are a field that thinks "move fast and break stuff" is actually a good idea. That kind of thinking works when you're slinging viral social media and personal productivity services, but it is catastrophic when you try to move into an industry where your customers' lives or livelihoods are on the line.
Yes, it is insanely frustrating. I think I did fairly well in law school in part because I wrote a program to auto-format my cites, which saved me hours of mindless, awful, pedantic, irrelevant blue booking.
>The firm charges their clients on an hourly basis, so they don't really have an incentive to be more efficient.
While I agree that the billable hours system reduces the incentive to be more efficient, I don't think it removes it entirely. Otherwise lawyers would still be using typewriters to draft memos. In my experience, removing some of the inefficiencies frees up time and mental bandwidth to focus on activities which actually benefit the client. More time reading cases, researching, evaluating issues. And you can bill for that.
You hit the nail on the head, there is an incentive to automate legal services ala legal zoom but for lawyers themselves the more tedious and paper based the process is the more they can make.
Hourly billing is (very slowly) going away. Fixed fee arrangements will be king (people want predictability). So then a lawyer will want to be as efficient as possible. The legal industry is admittedly behind the times, but they do continue to move forward.
I have a family member who is a lawyer and who has a similar type of software setup. The biggest obstacle I notice in the legal industry is that many simply don't care. They actively dismiss software as being unimportant even though they rely on it every day. It's a very bizarre case of the legal industry hating the very industry that could help them.
Note: perhaps my experiences aren't representative of the industry as a whole.
This is exactly correct. As a lawyer and a software developer, I long ago gave up on the idea of selling software to solve the problems of lawyers and/or law firms. Lawyers tend to be terrible customers of technology, if for no other reason than that they have established completely backward incentives that reward inefficiencies and information deficits.
The only "legal tech" that can succeed (in my opinion) is the kind that eliminates the need for lawyers, but then you're up against a different problem: people who think lawyers are magical wizards who can invoke spells to keep lawsuits and regulators at bay. It's really hard to convince many people that they don't need a lawyer, even though lawyers and law firms are almost never accountable for the advice they give.
I agree with eliminating the need for lawyers for most things, but the biggest problem about it is that in small cities/towns (maybe big ones too, I just have no experience in that domain) judges and lawyers are "buddies". People with the exact same charges can get radically different sentences depending on if they have a paid lawyer vs no lawyer or a public defender. There's a public defender in my town who also has his own private firm, and it's amazing how differently the judge and DA respond to whether or not you hired him or the town did. If all of that isn't bad enough, you can see the judge, DA , and lawyers all making backroom deals and exchanging favors. And they do it fairly blatantly in my town. I've rarely seen an objective case and it's a shame because law is perceived as a "sacred" domain where objectivity rules.
If you're going to court, bring a lawyer. Courts are the domain of arcane procedures and common sense has no place there. My comments above refer to transactions, compliance, etc.
Probably smart to bring one to court with you but maybe not required for drawing up a standard will where the few assets you own should just go to your next of kin
Lawyers write human readable code that's compiled and run by a judge or interfacing APIs (institutions such as financial ones)
Your advice is akin to saying "hey you inexperienced coder, write some production ready code but don't test it and when the only time it needs to run, give it a try. Hope you don't screw it up! When there's another coder in the room who can claim 'oh no he meant to set my financial variable 100X not 10x' and can convince the compiler to agree with them"
This analogy falls apart pretty quickly. You can't compile legal work product and no one is accountable if it doesn't run, unless you're at the point where malpractice comes into play. Malpractice is really, really hard to prove, though.
But most judges are making subjective decisions and not just "running code". The US constitution is law; can you compile it into code such that a computer could tell you whether a particular piece of legislation was unconstitutional? If you could, why hasn't such a computer replaced most of the US Supreme Court?
I investigated doing a SaaS product in the legal space. One of the things I heard multiple times from lawyers is that they are more likely to buy a product if they can bill their clients directly. What you are talking about would not fall into that category. That doesn't mean you couldn't build a successful business, but I think it is important to understand that the market has different rules.
I've heard the same thing from multiple people attempting to build for the legal space. Lawyers won't pay for software to save time because that has a negative ROI for them. OTOH they may pay for tools that helps them provide more services, bill more time, find more clients, or decrease the chance of mistakes.
> OTOH they may pay for tools that helps them provide more services, bill more time, find more clients, or decrease the chance of mistakes.
But... saving time means they have more time to provide more services, accept new clients, and review their documents to decrease mistakes. Is the relationship not apparent in their minds?
That was done in the UK. I wrote the first working version for Legal Cost Finance, who offered instant credit facility "to make justice affordable to everyone". It took them 3 years to take off even when the whole case was that they literally brought bulk of pre-paid (!) customers to legal firms.
Can you explain what you mean? Letter generation etc is still usefull, I don't see what billing has to do with it. They can still charge what they want to.
I think he means pricing schemes are more simple when you go with a flat "200$/hour rate". Obviously it's shit for the client since they have no idea how many hours will be spent on the case, but that's not the lawyer's problem.
Sure. The purpose of a SaaS product would be to improve efficiency and save time. Given lawyers typically charge by the hour, they would lose money unless they could bill their clients directly for the use of the more efficient software to make up for the lost revenue due to saved time. However billing clients for legal software is not the norm.
You most likely program in vim or another vi successor. Possibly with a ton of configuration settings and plugins that weren't around in vi. Big difference.
Fair enough. It is vim -- I still refer to it as vi because I'm that old. And yes, I do take advantage of undo and syntax highlighting. I'm sure quite a few of the modalities I use over the years have been added (oh! Tabs, very important). But the point is, relatively old control interfaces can be very effective even after 30 years.
Lots of commenters here have mentioned parts of law practice that involve lawsuits, complex negotiations, and so forth.
Workers Comp, Social Security, Family Law, and elder law in general aren't as glamorous. Clients for those services don't have such deep pockets as the other corners of the law do.
It's likely that a good SaaS-based system with embedded knowledge of jurisdictional rules (in the US, federal and state rules) could be successful.
But the sales cycle for a new product? Getting early adopters? Prepare for some pain.
I always thought there should be a one year masters of law program - no path to practicing, but gives you the frameworks and knowledge to be a good consumer of law
That's interesting! A1 looks archaic. An interesting startup in this space is https://www.upcounsel.com. They provide document management, calendaring and the such but operate as a marketplace platform. Would absolutely agree that the barriers to entry (compliance etc.) seem to be a big opportunity to offer solutions in the law space. As an interesting note: It looks like UpCounsel serves primarily as a marketplace due to upending the current law firm system which other comments have mentioned as a big barrier to technology adoption in the space. Interesting space nonetheless!
For contrast, I went the other direction. I taught middle and high school math, then got an MS in math (really enjoyed TAing) and started programming. I really appreciate the intellectual stimulation; I love the fast pace with which ideas evolve in the community. But I miss being that teacher who helped someone "get" math.
One of the coolest experiences I've had: one of my students managed to end up in my class for 6th, 7th and 8th grade math... Then 7 years later I hired her as an intern! She totally crushed the internship. Meaningful relationships with students like that, where they still check in occasionally and give me updates on how they are doing and tell me how I changed the way they see things... that is something I miss a lot.
For what it's worth I still think pretty often of my high-school math teacher who helped me "get" Calculus, almost 20 years ago. I wouldn't have my current programmer job and interest in abstract things if it weren't for him.
I started using it lot more in the past year, mainly since it hits every platform my kids, parents, and ex use. Which is all of them, at any given moment. Being the family techie, I was the only one to note that we were virtually limited to 1 or 2 choices.
