In this final installment we spend time talking about the problems associated with creating software that actually works. For something that Judges and mathematicians seem to say is so trivial software sure doesn’t work nearly as well as it should. Copied code cobbled together leads to broken systems, and programmers simply throw code up without proper vetting and let consumers find the bugs. Sure doesn’t sound like it is all that trivial to me, but then again, I’m not an ivy league educated Supreme Court Justice who is so computer illiterate that I don’t use e-mail.
To begin reading from the beginning please see A Conversation about Software and Patents.
Without further ado, part 3:
QUINN: Yeah, that’s exactly right. And I think if you look at the biotech industry what we see is that once Diamond v. Chakrabarty gets decided in 1980 the biotech sector in the U.S. took off. That decision was significant because the U.S. was not the historically dominant player in biotech and now we are almost to the exclusion of everybody else. I know there are good companies everywhere, of course, but the density here in the U.S. is much higher—much, much higher. If history proves true, the Supreme Court changing the patent laws and declaring vast categories of innovation patent ineligible will lead to fewer jobs, fewer startup companies, and companies that do exist relocating elsewhere.
ZEIDMAN: Right. And there should be an engineering approach to changing the patent system. If something is working you can make things more efficient by tweaking it. But you do the tweaks, you do it on experimental basis, or better yet you look at other things that have worked. So if we were going to ask why are we falling behind Europe, we’d have to ask, well, where are we falling behind? We’re certainly not falling behind in software innovation or any kind of innovation that I know of. So why would we look at that and say, oh, we need to revise our system to be more like Europe when we are much more advanced in that respect than Europe? But maybe there is something that Europe’s doing better. Maybe in, who knows, in agriculture. So let’s then let’s look at what they’re doing and see how it’s different than what we’re doing. But when we’re in the lead, when we are the most advanced nation on earth, why are we looking somewhere else for our model, whether it’s Europe or anywhere else, that’s not doing as well as we are?
QUINN: I couldn’t agree more. And I guess you know at the end of the day we’re left with what does all this mean? As a software expert who understands code, you’ve seen the technology side of this for a long time now. Let me ask you: What risk do you think we run? What fears do you have?
ZEIDMAN: My fears are that there will be less incentive to innovate. I think that we are currently innovating in software. I don’t think we’re innovating enough, though. I do think that there is a lack of talent in the U.S. and that’s maybe another topic. But maybe it’s related. I don’t know how to show the cause and effect there but I do believe that we don’t have enough programming talentDifferent organizations have gone back and forth and debated this. But I can tell you as a hiring manager that we have people who write software here but it’s not very innovative. First of all, I think that patents and the potential for monetary reward motivate people. In fact, I remember one thing that bothered me in the late 90s during the Internet boom that I met a lot of young people who wanted to be CEOs because they wanted to make a lot of money. And I think making money is terrific, but you’ve got to have a skill. You can’t just jump to the top of a company and not know what that company does. And so money motivated a lot of people to go to business school. I think it was a bad motivation. But if patents can make you money or secure your invention against competitors for a limited amount of time, then that’s an incentive for more people to do programming and do it right. And I think we’re losing that. It’s a complex issue. I’m not sure it’s all due to patents, but certainly for me, if I can’t hold onto my innovations in software I’m more inclined to go into some other field.
QUINN: Yes, because you can’t do this for free. There are only so many hours in the day and if you aren’t going to be making money doing something then you’ve got to figure out how to put food on the table and a roof over your head.
ZEIDMAN: Yeah, and you know there is also is this strange thing going on which again is probably another topic, but the whole open source movement which I predicted would not do as well as it obviously has. There are a lot of people willing to work for free, and I don’t completely understand that. But then you see things like the OpenSSL Heartbleed bug and realize that not all these people are doing great innovative things for free. And they don’t have the checks and balances that you have when you’re doing it for profit.
QUINN: Well, that’s right. I was just going to bring that up. In my little space what I see is open source is an extremely mixed bag. I see a lot of people doing stuff for free. And they’re doing it in a very business responsible way initially in many cases. They’re doing it for free because they have a plan, they’re going to build this, they’re going to give it away, they’re growing their reputation. And then they get to a certain point when they just can’t do it any longer. They’re making money and they’ve got clients and they can really no longer support the free stuff that they were giving away previously. I also see a lot of this open source stuff that’s free, particularly something like Word Press where it really relies on plug-ins to create the functionality. There’s all kinds of people that create free plug-ins. You can download them and use them and then they cease to be updated and then they become vulnerable to hackers and that creates a mess. It really is a mixed bag. You really do get what you pay for after all. I think the other thing with the open source, a lot of these people are working on a service economy. It’s free to have initially but then if you want somebody to customize it or to keep it running or to keep it safe and secure then you have to pay.
QUINN: And I also wonder whether this could describe some of the problems that we see with a lot of software. As you just said isn’t particularly innovative, it’s not particularly new because everybody copies everybody else.
ZEIDMAN: Copying is a big issue. In fact, I wrote a blog a little while back called Is Googling replacing programming? Because I was hiring people at one point where in order to solve a programming problem they would simply Google for the solution, find the code and copy that code. I’m not suggesting there was any copyright infringement because the code was allowed to be copied, but what happened was they didn’t understand what they were doing. And if it was bad code it just got multiplied all over the place. I think there is a problem and that relates back to what I was saying earlier that we don’t have the kind of engineering talent that we should have because people are not learning to innovate, they’re learning to copy what other people have done already.
ZEIDMAN: You know there’s a guy who wrote an article that I found really interesting. A guy named Jaron Lanier who’s one of the founders of virtual reality. Are you familiar with him?
ZEIDMAN: He’s an interesting guy. If you look at him you wouldn’t think that he would have a capitalist way of thinking about the world. And I don’t think he always did. He’s got dreadlocks and he doesn’t necessarily look the capitalist part. He’s been critical of the open source movement for these exact same reasons. He says it’s not innovative. People don’t have the motivation. And people are giving away stuff for free when they should be charging for it. One thing I don’t understand, which I thought would destroy the open source movement but hasn’t, is all these people around the world that are programming for free and who’s benefiting? The companies that sell the services to support the software. So these open source programmers are making some companies and some people extremely wealthy off their free labor. I don’t understand why these open source programmers aren’t upset about that.
QUINN: Yes, not only those companies, but the companies that get paid to fix code and close security vulnerabilities are getting rich too. I don’t get that either, why would someone work only to give it away? But I also think that in the light of the fact that you can’t almost go a week without some major hacking event, or now with the Russians having stolen hundreds of millions of passwords and email combinations, at what point in time do we start to really want to rely on proprietary, vetted, tested software that has somebody who’s going to stand behind what they’ve done?
ZEIDMAN: Well, it’s interesting you should mention that because I’ve just started a new company, called Zeidman Technologies, that automates some aspects of software development. We have a code generation tool called SynthOS, and every program that it creates is unique. There’s no code that anybody can examine. This relates to one of the issues that I’ve predicted about open source. A lot of my programmer colleagues didn’t believe me but I think we’re seeing this now. With open source code, anyone in the world can examine any piece of code and run all kinds of tests on it to find its vulnerabilities. I don’t understand why that security issue wasn’t more of a concern. I’d be curious if you have some thoughts or one of your colleagues has some thoughts about liability issues because it seems to me that when everybody is using the same code and it’s found to have some kind of vulnerability, it opens up everybody to litigation. Whereas if a company had their own proprietary code, not only would it be more secure, but if somebody gets hacked , it’s just one party, one company who gets broken into. Nowadays if somebody’s using Open SSL and it gets hacked because of the Heartbleed bug, it seems like every company using Open SSL could be sued because they should have known that this had a vulnerability.
QUINN: I think that that’s true. I think you’re going to find that the plaintiff’s lawyers will solve a lot of these problems with security and relying on things that are open and easily hacked and have security vulnerabilities. The same way they did when Ford was selling automobiles that they knew that were dangerous, people were dying and they didn’t do anything about it although they had come up with a fix. Not to suggest that people are dying, but identity theft can cause catastrophic problems, not to mention the financial losses from hacking one’s bank account. Generally speaking though, the story is informative. Ford got sued, they lost a lot of money, they got the bad PR in the press, and things changed. And I think that that’s going to happen at some point in time with software vulnerabilities. I think that it’s surprising it hasn’t happened already to be honest with you. I think we saw some of this when Target had their problem fairly recently. They had a significant drop in sales that led to the CEO leaving.
QUINN: And one of the other problems that I find a lot of times is if you’re trying to get somebody to work on something that’s open source that they didn’t create and they’re not familiar with, it’s problematic because they’d almost be better off starting from scratch and doing it their way so that they know how everything’s happening and they know where all the problems are from a debugging standpoint.
ZEIDMAN: Absolutely. My own experience was that we have a tool CodeDiff that finds differences in lines of code between the source code of two different programs. My original thought was that I’d go get an open source diff program; these things have been around for years. But I need to report some metrics about the differences—percentages of differences for example. So I thought well I’ll just get some open source code program that finds text differences and determine where in the code it’s finding out the differences, and I’ll put in some variables that keep track of that, that just keep count, and then I’ll put in code to print out some statistics. Now I’ve been programming for a long time, and I can’t remember any code that I couldn’t figure out. And for a living I reverse engineer code and testify in court. Yet I could not reverse engineer this code. Every time I touched it to make some kind of change to test it, the whole thing broke. And I finally had to write the code completely from scratch because this open source code was such a kludge, such a mess, that it was impossible for me to figure out.
QUINN: I hear you. I feel your pain. I mean we’re going through right now. We will still use WordPress, but we are going through a redesign and having it custom coded. We have been getting hacked, we get denial of service attacks, we get all kinds of things coming at us every single day, which maybe says a lot about the anti-patent community, I don’t really know how much of it’s coming from the anti-patent community. I think some of it is definitely coming because people don’t like what we write, but you really do wind up just chasing your tail.
I think we’ve come full circle, to some extent at least. We’ve just been talking for a little while about all the problems, all the things that can go wrong with software that is apparently so easy to write that college student with virtually no training can do it.
QUINN: And it’s so laughable. Computer implemented processes drive the economy and they’re rife with problems, yet it is so simple. And that perfectly explains why the Supreme Court is out of touch, they think it is so easy but even simple, non-inventive software doesn’t work or at least needs constant tweaks. You have to constantly try and stay ahead of the game and sometimes you have to just totally start over with your own code. I’m not suggesting any of these things that we’ve talked about are patentable, but even with something that’s not patentable because maybe it’s not new or it would be obvious, there are very real problems every day. And to think that you could just sit down and write code for something that has never been before without any issues or innovative steps is just wrong. Truthfully, it would be innovative to create a computer implemented process that works 100% without errors or vulnerabilities, but these judges just don’t understand that reality.
ZEIDMAN: You know, there’s a bunch of issues here and maybe some of them are that programmers nowadays aren’t well trained and they’re not well disciplined in programming techniques. In fact there’s a trend away from that. There’s this software development process called Agile Programming and Pair Programming and there was Extreme Programming, but all of these things say, hey, write code as quickly as you can, throw it out there, people will debug it for you. So first of all maybe we need to be teaching more discipline to programmers. We need to make the standards higher for giving programmers degrees, or if not degrees at least some kind of certification. And then convince them, hey, now that you’ve really gone through a rigorous program it’s not just okay to throw stuff together but create something with a structure that’s debuggable, that’s understandable, and that is innovative and patentable.
QUINN: Well, that’s funny that you say that because it feels like programmers a lot of times just throw up whatever. And that is not the engineering mentality. The engineering mentality is to look at this whole thing as a system and you have to take into account everything that can go wrong because everything that can go wrong will go wrong. To paraphrase Donald Rumsfeld, there are things that you know and there are things that you don’t know. You can adjust for the known problems but there is always going to be unknown problems. So if you just threw something up to see what happens without really sketching out the whole system and how it needs to work, you’ve just created so many more problems.
ZEIDMAN: Yes. And that is frustrating. Because that is the attitude these days. Throw stuff out and your customers will find the problems.
QUINN: I know we’ve been going for so long, I really appreciate you taking the time here. But let’s go back to where we started. Maybe a way forward with respect to drafting these types of patent applications is to really spend the time to explain that there is a “there” there, explain all the aspects and what’s going on from a technical perspective in much more of an engineering way than a lot of these software patents may have otherwise been written.
ZEIDMAN: I think that seems like a good idea to me. Obviously, you’ve still got the fine line you have to figure out, and this is up to you guys, the attorneys, to figure this out. How detailed do you get with the claims? The more detailed you get the narrower your claims are, but the broader they are the more they seem like abstract principles. Maybe the solution is to have many claims, varying the scope from very broad to very narrow, to try to really capture the crux of the innovation. Maybe that is the future of software patent claim drafting.
QUINN: I think you may be right. On that note let me say thank you again. I think this was a great conversation.
ZEIDMAN: Sure, Gene, I appreciate your asking me.