Creating Software Obviously Isn’t Easy – Part 3 with Bob Zeidman

Software expert Bob Zeidman

Bob Zeidman is the president and founder of Zeidman Consulting, and he is also the president and founder of Software Analysis and Forensic Engineering Corporation. Zeidman is a software expert that I have known for several years and in the wake of the Supreme Court’s decision in Alice v. CLS Bank we talked on the record about the decision, software in general and writing patent applications. What follows is part 3 of our 3 part conversation.

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.

ZEIDMAN: Yes.

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.

QUINN: Exactly!

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?

QUINN: No.

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.

ZEIDMAN: Right.

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.

ZEIDMAN: Right.

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.

 

Share

Warning & Disclaimer: The pages, articles and comments on IPWatchdog.com do not constitute legal advice, nor do they create any attorney-client relationship. The articles published express the personal opinion and views of the author as of the time of publication and should not be attributed to the author’s employer, clients or the sponsors of IPWatchdog.com.

Join the Discussion

11 comments so far.

  • [Avatar for Gene Quinn]
    Gene Quinn
    September 22, 2014 08:34 pm

    Stephen-

    First, you misrepresent Bob’s statements, which I suspect is on purpose. If you really read and try and understand what he says you wouldn’t be so confused.

    Second, you say: “Just about every software developer I know of recognizes that making secure and reliable software is very difficult.”

    Yes, it is extremely difficult. So difficult that it is actually impossible to do, which is updates and patches are always required. That is why software should be patent eligible. Doing it right is NOT trivially easy as some erroneously like to pretend.

    You say: “The work to be done is typically obvious to the programmer, even if not to the general public.”

    You probably think that statement helps you, but it completely undermines your argument. The question isn’t whether the invention is obvious to the inventor, the question is whether it would have been obvious to others.

    You say: “There may be good arguments for allowing patents on certain novel software algorithms…”

    Algorithms are not patentable.

    You say: “Supposing one did include every detail of the software’s operation among the patent’s claims, perhaps the entire software could be patented…”

    That is not what is required. You do not need limitations for each and detail of the software in the claim of a patent for the software claim to be allowable.

    It strikes me that you are not at all familiar with patent law, of course that doesn’t seem to have prevented you from having an opinion. Your opinion would be far more informed if you took the time to educate yourself on patent law. Until then your uneducated and uninformed opinion is really not particularly helpful. You simply cannot base valid opinions on faulty factual understandings.

    -Gene

  • [Avatar for Stephen Edie]
    Stephen Edie
    September 21, 2014 06:38 pm

    For all of his purported expertise on software, I’m surprised that Zeidman argues for patentable innovation as the solution for software security and reliability problems. His claims imply that for any software project there exists some secret sauce in the form of patentable algorithmic solutions that enable software to run without fault. He also argues that software patents should exist because software is hard to make, and he reasons that many in the software industry are opposed to software patents because they don’t appreciate the difficulty of the work they do. This is way out of touch.

    Just about every software developer I know of recognizes that making secure and reliable software is very difficult. The issue is that making software secure and reliable is not strongly related to innovation. It mostly requires mundane effort that nevertheless requires a programmer with great skill to perform. The work to be done is typically obvious to the programmer, even if not to the general public.

    I would even go as far as to say that the urge to innovate, either for commercial reasons or to bolster one’s reputation as an open source programmer, often contradicts the goal of secure and reliable software because fewer resources are dedicated to these mundane processes. I have witnessed this frequently both in proprietary and open source software development.

    There may be good arguments for allowing patents on certain novel software algorithms, although such claims will be very difficult for a patent office to fairly evaluate. On the other hand, patent protection should not be granted where the only novelty is the implementation of an existing process or algorithm on a computer. This is what the court says, and I think it’s unequivocal and makes perfect sense. This is not to say that such implementation *as part of a complete software package* is necessarily easy, but just because it requires hard work doesn’t mean it is or should be patentable. Supposing one did include every detail of the software’s operation among the patent’s claims, perhaps the entire software could be patented, but I imagine such a patent would be of little commercial value. The same software could be re-written using a slightly different implementation and achieve the same result.

  • [Avatar for Anon]
    Anon
    September 1, 2014 01:23 pm

    Not to be cynical, but I wonder if there is some form of passive/aggressive sabotage afoot given the pro-software patent leanings of the blog host…

  • [Avatar for step back]
    step back
    September 1, 2014 01:21 pm

    NWPA

    As I was mentioning, it appears that everything having to do with generic computer technology and whatnot is “obvious”, “mere abstraction” and doable over a weekend’s blast of “coding” for the 9 blackened robes and even some on the CAFC.

    So it should be no big thing for them to jump in here and help fix the comments problem.

    How hard can it be?
    Just say the magic words and it is done: bug begone!

  • [Avatar for NWPA]
    NWPA
    September 1, 2014 08:41 am

    GQ: I don’t know why, but there were a bunch of comments in the spam folder.

    It makes it very hard to have an interactive comment section on this blog. I suspect the reason some blogs like patentlyo have so many comments and this one doesn’t is because it is hard to comment on this blog. Not so easy to respond to a particular person and often the comments are held up.

    It is too bad as the content appears to me to be better than any other patent blog.

  • [Avatar for Gene Quinn]
    Gene Quinn
    August 31, 2014 04:48 pm

    Step (and everyone)

    I don’t know why, but there were a bunch of comments in the spam folder. Will try and get to the bottom of what is going on this week. Sorry for the inconvenience.

    -Gene

  • [Avatar for step back]
    step back
    August 30, 2014 01:05 pm

    Testing because all comments in all posts appear frozen

    Maybe a CAFC judge can help debug this trivial software problem?
    The solution must must be “obvious”.

    (Hint, descramble the encryption codes)

  • [Avatar for SadPanda]
    SadPanda
    August 29, 2014 02:39 pm

    Actually, I would argue that there is plenty of prior art for software that works.

    However, software that works requires time, money, and discipline.

    I work in the industry. There are very very few companies that have the discipline to rigorously test code. There are even fewer who RECOGNIZE the worth of having their code tested. Black Hat security experts always walk a fine line between being sued by companies or getting their jobs done. A disciplined company works hard to remove bugs, rigorously tests their software, and responds quickly to bugs that are found. I am fortunate I work for a disciplined company (we did go through a period where we had a bad actor who buried bug reports, that person was fired from the company when it came out, and the company put all new production on hold and spent 10 months doing nothing but fixing and testing on the product).

    If you want to know if the software you are using (be it closed or open sourced) is being written properly, don’t look at the bug that’s happening right now (IE: Heartbleed). Look at the RESPONSE to bugs. Computer programmers are human, we are going to make mistakes. If the company sits on bugs for a year (or if the open source project working on it doesn’t release bug fixes regularly), avoid that software when at all possible, and that company.

    If the company is making public threats against people who find bugs in their software (This isn’t something you can watch for with OS software normally, as there’s no legal group who file lawsuits for computer access violations usually, although I suppose Redhat could if they wanted to, they have a legal department), that is an actor you want to have as little to do with as possible, because they are not working on having their software not have bugs, they are providing security through hiding bugs. And believe me, people who bypass security for a living love undisclosed bugs, because they can be exploited over and over and over again.

  • [Avatar for Gene Quinn]
    Gene Quinn
    August 28, 2014 11:05 am

    SadPanda-

    I don’t disagree with your assessment about security. There are many low tech problems that cause security breaches. Phishing emails are but one very low tech way to get unsophisticated individuals to turn over the keys to the kingdom so to speak.

    I just point out that at one point you say: “when it comes to major security breaches, you’re usually looking at a combination of a bug in a program…” The bug in the program is a software issue. While it is unrealistic to think that no bugs should ever occur, it is also unreasonable for the industry to provide software products that have so many bugs. Consumers are nothing more than beta testers any more.

    The fact that there are so many bugs logically undercuts the argument that software isn’t something special and shouldn’t be patented as an innovation. If it were so easy then there should be no bugs. But there are numerous bugs that can’t seem to ever get completely fixed before new bugs surface. This proves the point that software is more of a dynamic system than a static, easy, objective undertaking.

    Would anyone doubt that software without bugs that worked as advertised would be innovative? It would indeed be innovative because it would be new.

    -Gene

  • [Avatar for SadPanda]
    SadPanda
    August 27, 2014 06:26 pm

    Gene, breaching of security is often significantly less about what software you are using (be it open source or proprietary) than it is about the user’s complete and utter lack of security competency.

    A lot of those breaches are not because of the software being used (proprietary or open source). It’s because the companies in question do not follow best practice with regards to securing their sites and networks in the first place.

    Apple comes to mind, with their website that used i-phone serial numbers in the URL to pull up account information.

    Companies leaving unsecured unencrypted databases lying on publicly accessible servers…

    Critical Patches not applied in a timely manner because ‘no budget for that!’.

    Sloppy network configuration (leaving a network machine outside the firewall that has information on it, or has open port access to a machine inside the network).

    I could go on for hours just on things I’ve actually seen in the industry. And we’re not talking about small players or open source here, I’m talking about major government entities, large companies, IT corporations, all being less than concerned about their security setup… until it bites them. Then people have the budget for it. After the horse is out of the stable and it’s been burnt down.

    Yes, there are some critical bugs that pop up (Heartbleed, the literally uncountable zero-day exploits in Internet Explorer, Adobe Caching exploits, android app security bypasses, apple app security bypasses) that are inherent in the application you are using. But when it comes to major security breaches, you’re usually looking at a combination of a bug in a program (closed or open source) combined with a lack of security consciousness (or a belief that ‘it costs too much’ to do a security review/patch/upgrade/etc) or just a lack of security in the first place.

  • [Avatar for Anon]
    Anon
    August 27, 2014 10:17 am

    True innovation (in the model of disruptive game-changing innovation) is not in the best interests of established powers.

    This fact alone should be prominent in any discussion of patent systems, changes to patent systems and noticing which market players are pushing for what types of changes in patent systems.