Is LinkedIn Premium Worth It?

The Short Answer: No.

The Long Answer: As a job-seeking software engineer, I don't think LinkedIn Premium is worth the cost ($39.99/month). I reached that conclusion after using the free one-month trial and spending time with its exclusive features.

Opinions on the internet are mixed about whether LinkedIn Premium offers a meaningful advantage in the job market¹²³⁴⁵. Supporters point to features like seeing which recruiters viewed your profile, messaging those recruiters directly, and receiving application insights that estimate how well your resume matches a position. In my experience, however, none of these features had a meaningful impact on my job search.

First, the ability to see which recruiters viewed my profile didn't provide much of an advantage. Just because a recruiter viewed my profile doesn't mean they'll respond to a message. In fact, I've never received a response after reaching out to a recruiter first. If a recruiter is genuinely interested, they can message me—and as recruiters, they almost certainly already have LinkedIn Premium through their employer.

The feature I used most was "Jobs where you'd be a top applicant." It highlights recently posted jobs that LinkedIn believes closely match your experience. It's a useful feature, although not a perfect one. It frequently recommended full-stack and frontend positions, even though I'm exclusively a backend engineer.

I eventually realized that these recommendations rely heavily on the Skills section of your profile—a section I had largely neglected. Improving that section only slightly improved the recommendations. Even then, LinkedIn's search and filtering tools remain fairly limited. There's no equivalent of a negative regex or exclusion filter, so you'll still spend time filtering out irrelevant positions.

Some info censored for privacy reasons

Another selling point of LinkedIn Premium is access to LinkedIn Learning. Personally, I found most of the courses to be fairly introductory. For the topics I was interested in, classes I've found on LinkedIn were rudimentary and lower in quality than what you can find on YouTube for free.

Finally, paying LinkedIn for the privilege of fully using its own data feels a little backwards. It reminds me of paying a headhunter to help you find a job. Traditionally, job-search platforms have been funded primarily by employers and recruiters rather than by job seekers.

That said, the strongest reason to use LinkedIn isn't Premium—it's the network itself. Nearly every professional software engineer I've worked with has a LinkedIn profile. Over time, your coworkers become your professional network, giving you a large pool of current and former colleagues (along with the occasional recruiter) that you can reach out to during your next job search. None of that requires a Premium subscription.

LinkedIn's job board is also reasonably useful, although I still think it's underdeveloped due to its meager filtering options. Its biggest advantage is the integration with your network. Once you discover that a company you're interested in employs someone you know, you can ask them for that sweet, sweet job referral. Again, that's entirely possible with the free tier.

To be fair, there are situations where Premium may be worth the cost. If you're pursuing a particularly niche role or have been searching unsuccessfully for an extended period, spending $40 for a month or two to gain even a slight advantage may be a reasonable investment. Job searching can be exhausting, and even small improvements to the process can make it feel more manageable—even if they don't ultimately land you the job.

Footnotes

1. https://www.linkedin.com/posts/courtney-paraski-33544672_my-honest-review-was-linkedin-premium-worth-share-7381786673992429568-jUcL/ (not worth it)

2. https://www.trykondo.com/blog/linkedin-premium-worth-it (only if active seeker in "high demand" industry)

3. https://www.quora.com/Can-you-explain-what-LinkedIn-Premium-is-and-whether-it-is-worth-the-cost (mixed)

4. https://www.reddit.com/r/careerguidance/comments/104vai3/linkedin_premium_is_it_worth_it/ (mixed)

5. https://www.linkedin.com/posts/jarrodbestmitchell_is-linkedin-premium-worth-it-if-youre-job-ugcPost-7386736395865858048-oD_O/  (yes)

Evaluating AI Models for Production

The following article isn’t sponsored by any organization and is solely the opinions and observations of the author.

I recently attended a software seminar on generative AI (GenAI) model evaluation. The event was hosted by TrackIt and AWS. The session promised to explore “how modern AI teams are benchmarking, testing, and optimizing large language models for production environments,” but the most valuable takeaway was a discussion how best to evaluate LLMs (large language models; generative AI models like ChatGPT, Claude Code, etc.) for real-world business use.

I found this topic particularly interesting because there is little guidance available on how organizations should choose an LLM for a specific project or business need. While model capabilities are discussed extensively, the process of evaluating and selecting a model is often overlooked.

This slide was crucial:

Sorry that I didn't get a better shot

It summarizes the three primary approaches to LLM evaluation:

1. Algorithmic (deterministic)
2. LLM-as-Judge
3. Operational (cost, speed, etc.).

The first and third are relatively straightforward. Operational considerations such as cost, latency, and vendor support are often the first factors engineering teams evaluate when selecting software. Similarly, there are dozens of deterministic LLM-evaluating benchmarks, such as Humanity’s Last Exam, GPQA Diamond, and others. There are numerous websites dedicated to comparing LLMs using these benchmarks.

LLM Metrics from Vellum

What was novel to me was the LLM-as-judge approach: using one LLM to evaluate the output of another. In this approach, you define the evaluation criteria and have a separate LLM score the responses generated by the model under test. Although this requires some upfront effort to design effective evaluation criteria, those criteria can be reused across all of your future evaluations. 

This approach is especially valuable when your intended usage has no objective ground truth, or when quality depends on subjective factors. While traditional benchmarks can provide insight into general model performance, they may not accurately predict how well a model performs on a specialized business task. For example, a benchmark score will not tell you which model is best at transforming a chef’s rough notes into polished, consumer-ready recipes for a new cooking website.

Let’s imagine you are building a cooking platform and have a chef who sketches recipe ideas in shorthand. You want an LLM to convert those rough notes into clear, complete, and professionally written recipes. To evaluate candidate models, you would create a collection of representative inputs (the chef's notes and the model instructions) and ideal outputs (finished recipes). Each model under evaluation would generate responses for the same inputs, and the judge model would compare those responses against the expected outputs using criteria you define. The resulting scores would provide a task-specific evaluation tailored to your business needs.

Some tips:

• Pick one or two judge models. One might think that the comprehensive way would be to use many different models. This adds significant complexity while providing limited additional value. In most cases, using your current production model, or a capable, low-cost model is sufficient.
• Use a small continuous scoring range, such as 1–5. Quality assessments are inherently subjective and thus should be rated with a range rather than a binary pass/fail. Conversely, a huge range (e.g. 1-100) implies a false level of precision.
• Don’t rely solely on LLM-as-judge evaluations. Combine subjective evaluations with the algorithmic and operational metrics. Those quick, easy, and deterministic methods add important color to the subjective method discussed here.

The key lesson I took away from the seminar is that selecting an LLM should not be based solely on benchmark rankings. The best model for a business is often the one that performs best on the organization's specific tasks while balancing algorithmic performance, subjective quality, and operational requirements.

Code: Kotlin First Impressions

Introduction
Kotlin is one of the newest and most popular JVM languages and it might be one of my new favorite languages. Disclaimer: I haven't written much production-ready code in it yet.

As a JVM language like Scala, Groovy, and Clojure; Kotlin tries to take the portability of the Java Virtual Machine and familiarity of the Java language while improving upon its archaic design with the conciseness and power of modern programming languages. Simply put: it's Java but better—for real this time!

Scala was my favorite attempt at improving Java, but I was pretty unhappy with the build system. Since Kotlin is written by JetBrains, an IDE company, compiler and IDE support is first-class. You can even use JetBrains' IntelliJ to output Kotlin code to Java, and vice versa. For this reason alone, it is easy to pick up for Java developers.

Improvements on Java 8
So what does Kotlin improve upon? Firstly, Java's verbosity. Compare a hello world program in Java:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello world!");
  }
}

and in Kotlin:

fun main() {
    println("Hello world!")
}

The first thing to note is that no class definition is required. You can simply add top-level functions. Kotlin is a functional language, so a function definition is required, but the public access modifier is implied. Top-level functions are always static. And type inference also applies to functions, so no void is required here. Just fun to mark that it's a function. In the actual function itself, println is a top-level function, so no need to qualify the function with a package and class. Lastly, no semicolons.

This is not some neat trick about hello world programs, the rest of the language is written to be concise. Record classes (data classes), raw strings, type inference, default function parameter values, string interpolation, collection builders, array slices, range operators, and null safety operators all help make your code very concise and efficient. If you don't know what those mean take the following Kotlin code:

fun doSomething(param: String = "default") {
  val stringTemplate = "$param ${1 + 2} String"

  val nums = (0..20).toList() // A list of integers from 0 to 20
  println(nums.slice(1..5 step 2)) // Prints "[1, 3, 5]"

  val newStr: String? = getStringOrNull()
  println(newStr?.length) // Prints length or "null" if string is null

  val neverNull = getStringOrNull2() ?: "" // Converts nulls to ""

  val regex = """\w+@gmail\.com"""
}

Doing this in Java 8 without special libraries would be like:

public static void doSomething() {
  doSomething(null);
}

public static void doSomething(String param) {
  param = (param == null) ? "default" : param;
  String stringTemplate = String.format("%s %d String", param, (1 + 2));

  List<Integer> nums = IntStream.rangeClosed(0, 20).boxed()
      .collect(Collectors.toList()); // It's either this or a for loop
  // A for loop is simpler than the stream version
  List<Integer> slicedList = new ArrayList<>();
  for (int i = 1; i <= 5; i += 2) {
    slicedList.add(nums.get(i));
  }
  System.out.println(slicedList); // Prints "[1, 3, 5]"

  String newStr = getStringOrNull();
  System.out.println((newStr == null) ? null : newStr.length());

  // We need two lines for this, unless we call the function twice
  String intermediateVar = getStringOrNull2();
  String neverNull = (intermediateVar == null) ? "" : intermediateVar;

  String regex = "\\w+@gmail\\.com"; // We must escape special characters
}

Or at least that's my interpretation. With Java 8 streams, there are a few functions to create and manipulate collections. You can also short circuit nullable objects with Optional.ofNullable([nullable]).orElse([default]), but I prefer the ternary operator in Java.

Another great feature is destructuring declarations. In Python, you can return multiple values. In Kotlin, we get half of that feature by being able to "destructure" a returned value into multiple variables:

  val (name, age) = person
  for ((key, value) in map) {
    // stuff
  }

Lastly, it is interoperable with Java. You can call Java code from Kotlin and you can even call Kotlin code from Java. One of Java's biggest strengths is the massive set of libraries you can use. These libraries are available, too, in Kotlin.

Drawbacks
Sounds too good to exist? Well, Kotlin has some drawbacks. I probably will come up with more after using the language for a while, but for right now, the drawbacks are minimal.

For one, variable type declarations follow the variable name as in var a:Int. For many of us, we started programming in C, C++, or Java where variable types come before the variable name. I disliked this seemingly arbitrary change until it was explained to me.

When declaring a variable, the variable's name is the most important aspect. When your language has type inference, the type isn't always written. This means variables declarations are generally aligned well, regardless of type declaration or lack thereof. This alignment is maintained for variables (val or var) and functions (fun).

val a = 1   // Infers type from value
val b: Int  // No value to infer type
var c: String = "String" // Optionally specify type
// Infer return type of single-expression function
fun sum(arg1: Int, arg2: Int) = arg1 + arg2

Notice that the val/var/fun keywords are all aligned vertically, as are the names. So while this name-type order will take some getting used to, it's not a bad thing. Pretty much all modern languages (Go, Rust, Swift, Scala, Nim, and Python) use it.

One issue that I dislike is the amount of scope functions. let, run, with, apply, and also are all ways to call a block of code with a temporary scope and each is used slightly differently. This seems like overkill and I don't imagine I'll ever memorize which is which. You don't want to have too many ways to do the same thing in a language, as it makes reading and reviewing code difficult.

Overall, it seems like a very fun, concise language and an upgrade to Java.

Kotlin vs Newer Versions of Java

JetBrains 2021 Developer Study

Having said that, Java has progressed quite past version 8. Java 8 is still the most popular version, according to a JetBrains survey, being used by 72% of Java programmers (users were allowed to select multiple versions). SNYK's survey results says Java 11 slightly outweighs Java 8 with both being around 61%. In either case, the higher versions of Java have little use with both companies saying Java 15 use is around 13%.

SNYK 2021 Developer Study

Java 19 will drop in September, but for a company looking for stability should probably stick with Java 17, as it is will still be the most recent version with Long-Term Support from Oracle. So what does Java 17 add to the language that Java 8 and Java 11 users may be unfamiliar with? I will describe some of the notable language updates, ignoring preview features and compiler and JVM enhancements.

Java 9 to 11 updates:

• 9: Project Jigsaw: Modular system
  Introduces a module system to the language to define exports and dependencies.
• 9: Private methods in interfaces
• 9: Actual immutable collections
  Allows things like Set.of(item1, item2).
• 10: Type inference
  Introduces var keyword.
• 10: Root certificates.
  Allows TLS out of the box.
• 11: HttpClient
  A replacement for HttpUrlConnection.
• 11: More String and Files methods
  New methods like String::lines and Files::readString.

Java 12 to 17 updates:

• 12: New methods in String, Files, and Collectors
• 12: A number formatter
• 14: Switch expressions
  Makes switch expressions much less verbose.
  
• 15: Text blocks
  Allows setting Strings to nicely-formatted multiline blocks of text without inserting pesky "\n".
• 16: Records
  Allows the creation of data classes with default getters and setters in essentially one line.
• 16: Pattern matching for instanceof
  Decreases verbosity by allowing the declaration of a variable in an instanceof expression.
• 17: Sealed classes
  Increases control over class inheritance.

Most of this article was written with Java 8 in mind. It's fair to say that Java has come a long way since then and Java now has more syntactic sugar. Specifically, type inference, text blocks (multiline strings), and records (data classes). However, even these new features are weaker than their Kotlin equivalents:

• Type inference only applies to local variables, not top-level variables or lambda expressions
• Text blocks aren't raw strings and will still process escape sequences (i.e. you still have to escape all of your backslashes). Writing regex in Java still sucks.
• A record cannot contain any private instance variables. Admittedly, this is a tiny disadvantage.

Even the work that has been done to modernize Java doesn't bring it up to par with Kotlin. That's why I'm excited to start using Kotlin.

Software Engineering: RAED for Permissions

 In any given important software being used by many people, access control is an important part of security. For example, I have the proper permissions to edit this blog and you do not.

But there's many ways to implement access control. For example, Unix-like file systems generally have read-write-execute permissions. A user, group, or "other" can each have a combination of permissions to read, write, or execute a file. An admin might use the chmod command to edit a user's permissions.

Windows implements file access control differently. There are permissions such as "Full control", "Modify", "Read & execute", and just "Read" that can be allowed or denied to a user or group.

Windows File Permissions

CRUD is another way permissions might be implemented. A user can be allowed to create, read, update, or delete files or other types of data in any combination.

At my last job I was tasked with coming up with an authorization system for our microservices. Rather than use some framework for authorization, I decided to build our own. I was replacing WordPress permissions, which were similar to CRUD. For any given type of page, a user might be allowed any combination of the creation, reading, updating, or deleting permissions, depending on what an admin had checked. For example, our online magazine had CRUD permissions. All of our customers could read the magazine. Specific content creators could create new articles and upload them. Editors could update anyone's articles to fix grammar, spelling, or links. Finally, admins could delete articles.

Designing permissions was important. We didn't want to give a user the wrong set of permissions, otherwise they might be allowed to delete important data. Or, with insufficient permissions, they might not be able to do their job.

I decided to use something I had previously created: RAED, a superior access control design for general-use permissions.

RAED stands for read-add-edit-delete and is a set of eclipsing permissions to be used with file systems, RESTful APIs, or anything else that requires access control. It's basically CRUD, but much better.

Other permissions become confusing when certain combinations are used. For example, what does it mean when you can write something, but you cannot read something? When would you be allowed to delete data without being able to update it?

With RAED, there is no confusion because if you have one level of permission, you have all of the permissions below (or to the left of) it. If you can add, then you can read. If you can edit, then you can read and add. And finally, if you have the delete permission, you also have the read, add, and edit permissions for that particular thing. For any given permission level, just makes sense to have the lower permission level. When will a user need to delete data, but should be forbidden from reading or editing that same data?

RAED is simpler to display. Instead of four sets of radio buttons (Allow/Deny) in CRUD, you have five radio buttons (the first one being no permissions). Example:

Database Permission:
None Read Add Edit Delete

RAED also can be stored with fewer bits, since there are only 5 possible values as opposed to the 16 possible values with CRUD and Allow/Deny. This is a very small benefit, since we generally store data in single bytes or larger, but it's definitely more compressible.

Can't remember the order of permissions? It's always RAED, like the Arabic name for boys.

RAED doesn't work for all access control systems and permissions, for example, when you only need a simple binary Yes/No for Can-Upload-Photo-Permission or similar. However, if this meets your needs, I highly encourage you use RAED.

Job Seeking: Crafting the Perfect Resume

In this economy, job seekers are at an advantage. Businesses are desperately seeking employees, not just in the service industry, but also in the tech industry. But that doesn't mean it's not important to put your best foot forward and craft the perfect resume that highlights your talents.

I have interviewed scores of software engineers and managers across three companies over a 13-year career. As a director I've made the final call on hiring several QA analysts, QA engineers, and QA managers. I've represented my company at several career fairs. So I know what I want to see in a resume.

This is one area I wanted to make sure I had a lot of experience in before I spoke publicly about it. I feel I have finally achieved that level of experience. Here is my advice.

Basics

A resume should list your skills, your technologies you're familiar with, your work history, and your education. There are a lot of good samples on the Internet. I have posted one below.

Work History

I've been told to make sure I highlight concrete, measurable accomplishments rather than job duties. That is, don't say "Responsible for redesigning backends", say "Streamlined backends, reducing wait time by 50%" if you sped up a backend request from 0.8 seconds to 0.4 seconds. But when I'm reviewing resumes, I am less focused on those achievements since some are easier to accomplish, depending on the company's existing technology. Additionally, many of those tasks were given by bosses and measured afterwards. That measurable accomplishment doesn't tell me much more than a description of the task you were given; it just tells me that you were successful at it. When I read work history, what I'm generally looking for are the technologies worked with, tasks given, and roadblocks overcome.

Similarly, use action verbs. Don't just say "did", "made", and "told". Use "performed", "implemented", and "documented". Once again, I see through that kind of stuff, but it's a good sign when you can use strong action verbs truthfully to describe what you accomplished at previous companies. For example, "documented" implies a permanence that "told" does not. Are they still using your research? Probably so if it was "documented." Probably not if you only "told" someone about it.

Definitely don't sell yourself short. Highlight your top accomplishments and phrase your responsibilities and leadership so that readers don't think you just played a small part in any projects that you led or had a massive part in.

Words Words Words

There is an exception to my apathy to big words: fancy words and flowery grammar show me that you have an excellent command of the English language. If I have any bias, it's a bias towards excellent English communicators. As a software engineer, I have worked with many people who didn't know how to communicate properly and it has occasionally become a stumbling block. It is sublime working aside engineers who can disseminate information widely and individually in a manner that is concise, precise, and unambiguous. Yes, I did use some SAT words there to make a point.

Don't Lie

Oh my god, don't lie. At Google, I once did a "coaching call" (mock interview) with an applicant who claimed he had been the leader of a local student organization. Incidentally, not only had I participated in that same organization, I actually knew the then-leader of the organization. While on the phone with this applicant, I realized something was suspicious and asked for clarification. He backtracked from his lie.

I would never hire someone who would lie about something small like an extracurricular activity. Saying you know Java when you only wrote a small Java app is a small stretch of the truth. Saying you held a leadership position you didn't actually hold is such a meaningless lie that it shows you can't be trusted at all.

Cover Letters: Unnecessary

A cover letter has never, not once, affected whether I wanted to hire someone or not. I understand that there is a level of effort in creating one, but that effort could go towards improving your resume or leveling up your interviewing skills. Anything important to know should be in the resume. Most times, I don't even read cover letters.

Resume Length: 1-2 Pages

It's hard to fit your whole life onto one page, especially if you've been at multiple companies. Now that physical paper is a thing of the past, a two-page resume is completely fine or even expected. Three is a bit long and four is ridiculous, unless you've had a very long, illustrious career. Stick to 1-2 pages. My current resume is 1.5 pages.

Fancy Design

Should you use column headers, multiple colors, a sidebar? I shy away from that. My resume is super plain; maybe even too plain. I do enjoy reading a nice looking resume, but don't go too fancy and make things difficult to read. During my current job hunt, I've filled out online job applications that scan my resume and fill out the application with the parsed results. I imagine these apps struggle on overly-fancy resumes.

An exception is when the role requires good design skills. I am impressed when a frontend developer has a nice resume. This may be foolish, but I suspect the skills in resume design may carry over into web design. But it's not required.

Customize to the Job

If you're applying to different roles, customize your resume. For example, I've applied to QA manager roles and engineering manager roles recently. Each time, I tailor my resume to highlight what the hiring manager wants to see and remove experiences and skills that are irrelevant.

Example

Here's a sample resume from Monster:

[image removed]

I find that most sample tech resumes on the Internet are pretty good, so follow those for the basics.

Policy: Our Broken Software Patent System (The Short Version)

I get it. Ain't nobody got time to read a 4,500-word article on software patents.  But I think this is an important topic, so I wrote a shorter version of my three-part article for impatient readers.

But first I have to plug two excellent sources of information about our broken software patent system: the This American Life episodes " When Patents Attack!" and " When Patents Attack ...Part Two". I cannot recommend these episodes of This American Life highly enough.

The Software Patent System Is Broken

The American patent system is completely broken, at least when it comes to software patents. Billion-dollar software companies are suing each other over minor pieces of code, patent trolls run rampant, and consumers are losing out as the original purpose of software patents have been lost.

The Point of Software Patents
Patents are a form of intellectual property, like copyright. Unlike copyright, patents cover inventions instead of creative works and last for a shorter time.  The idea behind patents is great: If you spend years inventing something, perhaps building a better mousetrap, then someone shouldn't be able to see your mousetrap in a store, steal your idea and sell the same mousetrap while bypassing all the hard work you did refining the improved mousetrap.  With patents, you must reveal your invention publicly, but then you have the exclusive rights to that invention for 20 years.

However, there are limits. You can't patent just anything, someone would patent the wheel and sue all the car manufacturers.  Patents must be a patentable thing (a process, machine, "[article] of manufacture," and composition of matter), and they must be  new, useful and nonobvious.

Applying these principles to software is pretty new. Software patents only became legal in the US in the 70's and 80's. The courts are still trying to figure it out.

Existing Patents Are Invalid - Non-New Patents
One problem with the current situation is that people are patenting things they shouldn't be able to patent. People are patenting existing software inventions.

During the "When Patents Attack!" episode of This American Life (TAL), the journalists from talked to David Martin, the founder of M-CAM. M-CAM uses special software to search through all existing software patents to find patents that are essentially the same. Ideally, each patent should be unique. However, sometimes the US Patent and Trademark Office (USPTO) grants patents for things that have already been patented. During the TAL episode, Martin looked up how many matching patents there were for one specific software patent. There were 5,303 matching patents.  Martin said that happens 30% of the time.

The specific software patent that Martin was looking up with TAL was Patent 5771354. According to the owners, Intellectual Ventures, it covers upgrading software on your home computer over the Internet.  When TAL looked at the text of the patent it seemed like it did a lot more than that. My own opinion is that it appears to cover doing any sort of data backup over the Internet, using an ID and password.

Drawing from Patent 5771354 showing
how all computer networks work

There are duplicate patents abound.  Furthermore, I'd argue that even if an inventor receives the patent on something, it doesn't mean he or she invented it.  That person may have just been the first to file a patent.  Filing a patent is an expensive, time-consuming process.  According to the USPTO, it takes about 2 years for a patent to be processed.  The cost of filing a software patent is around $10,000 (UpCounsel, Richards Patent Law, IPWatchdog) when including legal fees, which might be a drop in the bucket for a major corporation but is expensive for a small startup.

Existing Patents Are Invalid - Obvious Patents

Software patents might be obvious extensions of existing patents.  As a software engineer and a person who is skilled in the field, I would describe Amazon's 1-Click patent as fairly obvious.  As one blog pointed out, it's a "fairly broad concept" that the European Patent Office denied a patent to because it was "obvious to a skilled person".

Another example: Richard Stallman, a software engineer who is famous for his work on GNU, Emacs, and other free software, decries the obviousness of Patent 5963916, applied for in October 1996 in his text, "The Anatomy of a Trivial Patent".  Patent 5963916 covers listening to a preview clip of music on the Internet.  After posting a snippet of the patent, Stallman writes, "That sure looks like a complex system, right? Surely it took a real clever guy to think of this? No, but it took cleverness to make it seem so complex."  Stallman analyzes each line in the first portion of the patent to point out how each aspect of the idea was already existing or, at least, very obvious at the time.  The overly complex language commonly used in patents obscures the obviousness of the ideas.

Patents Aren't Serving Their Purpose - Patent Trolls
According to the most popular definition, a patent troll (also called a patent assertion entity) is a company that obtains patents--usually through buying them--and, instead of making products based on those patents, waits for another company to violate their patents, and then forces that company to pay licensing fees to use that patent.

Let's take the example used in the intro of "When Patents Attack!".  Since 1999, Jeff Kelling has been working for FotoTime, a small company that hosts a photo sharing website. In May 2008, they received a letter from FotoMedia (not to be confused with FotoTime) that said FotoTime was in violation of 3 patents.  FotoTime was told to pay licensing fees or risk going to court.  It turned out that FotoMedia had sent the letter to 130 other companies including Yahoo (Flickr), Shutterfly, Photobucket, and other companies, big and small.

Whatever patents were being violated, FotoTime had evidently come up with the same idea themselves, without reading FotoMedia's patent or copying some FotoMedia product.  Another weird thing was that FotoMedia had no photo-sharing website, so it wasn't a competitor to FotoTime.  When Kelling called FotoMedia to ask them which patents FotoTime was violating, FotoMedia wouldn't tell them until they went to court.

Kelling learned that fighting the patent in court would cost an estimated $2 to $5 million, which was "more than [FotoTime] could handle".  FotoTime settled with FotoMedia.

This is what patent trolls do.  They purchase a patent that is somewhat vague or perhaps even invalid, and instead of making some technology that uses the patent, they threaten to sue companies they think are using the patent.  Some companies will pay them a fee rather than spend millions of dollars fighting the patent.  The patent trolls will then use that money to purchase more patents and sue more people, over and over.

This isn't a business.  This is, as venture capitalist Chris Sacca described such practices on This American Life, "a mafia-style shakedown."

And patent trolls are growing bolder.  According to a Presidential study, the number of lawsuits brought by patent trolls more than doubled from 2010 to 2012, and these lawsuits accounted for 62% of all patent lawsuits in America in 2012.  Victims of patent trolls paid $29 billion in 2011.  Now in 2014, these numbers are probably higher.

Patents Aren't Serving Their Purpose - The Damage from Patent Trolls
Patent trolls kill innovation in a few ways:

1. Software companies must spend money on legal fees instead of growing their technology.  It's impossible to know whether your company will be violating a patent or whether a patent troll will target your company, so you must be prepared.
2. Some startups may not be able to pay the legal fees from a patent lawsuit and may go under.
3. Patent trolling can even create a chilling effect, causing programmers good ideas to never pursue their startup for fear of being sued by a patent troll.

Software patents no longer promote progress, if they ever did.  It's impossible to know whether a company is actually violating a patent because the patent office is a confusing mess, containing vague and duplicate patents.  And so any software company with a good idea can be sued at any time, by a patent troll claiming that software company is violating its patents.

The system needs fixing.

The Software Patent System Will Always Be Broken

Changing such a huge system to be efficient and coherent would be hard.  The software patent system is at the intersection of law and software engineering, an area few people understand well.  As such, it can be difficult to solve its problems or even describe what the problems are.

The Government Won't Fix the System
Firstly, the United States Patent and Trademark Office is unlikely to fix the software patent system.  For one, they are overburdened with work already. The USPTO has too many patents to process and too little time to process them.  I suspect that this extra amount of work has lead patent examiners to approve lower-quality patents.  A recent study also suggests that the patent office has lowered standards to cope with the huge backlog of pending patent applications.

Congress or the President could fix the system, but patent reform is not a sexy issue and is unlikely to get the attention it deserves.  Furthermore, I doubt the President or Congress understand this thoroughly complex problem.

The Industry Won't Fix the System
I doubt that software companies will fix the system.  Large software companies already have purchased hundreds or thousands of patents and are immune to patent trolls.  Small software companies are feel the most pain from this broken system, but they don't have the lobbyists to effect change in Washington.

Patent lawyers, whether they work for the government as examiners and judges or for companies as patent attorneys, have even less incentive to change the patent system.  The broken patent system is their livelihood, and a lucrative one at that.

The System is Intrinsically Unfixable
Another reason I believe the software patent system will always be broken is because the idea of software patents is absurd.  Software is inherently unpatentable.

Firstly, software is a fast-paced industry.  The next big thing is often deprecated in a short amount of time.  Let's look at smartphones for an example.  3G data was a huge selling point for the iPhone 3G in July 2008.  Two years later, HTC released the EVO 4G, the first 4G smartphone in the US.  However, that phone used WiMAX networking for its 4G capability, and WiMAX was declared dead as of 2013 or 2014.  All major US networks now use LTE for 4G data.  In less than 6 years, the way smartphones sent data over mobile networks changed multiple times.  Yet software patents last 20 years.  Twenty years is several lifetimes in software years, way too long to give exclusive rights to a software invention.

A second issue is that patents aren't as necessary for software as they are for hardware.  I understand the need for protecting hardware.  Inventing new mouse traps requires not just time, but materials.  You need to create lots of physical prototypes until you get it right, using real materials, like wood and metal.

"Inventing" software requires none of that.  All you need is one basic computer to program on and you can create endless prototypes without worrying about materials or trial runs in harsh conditions, unless you're trying to program for some specific device.  Even then, there are emulators that allow you to program apps for smartphones and vending machines, etc. without actually purchasing the device the software will end up on.

Lastly, the complexity of software causes difficulty in deciding their patent eligibility.  In Patent Failure: How Judges, Bureaucrats, and Lawyers Put Innovators at Risk by Bessen and Meurer, they describe how software's complexity hinders its patentability: "It is possible, however, that features of software technology make it particularly susceptible to the patenting of obvious ideas, especially given the legal doctrines of non-obviousness developed by the Federal Circuit."

Software is different.  Software might even be unpatentable.  But even if it isn't, the software patent system will always be broken because no one can fix it. That's why we must abolish software patents.

We Must Abolish (or Reform) Software Patents

The system is very broken, and why there's no hope that it will ever be fixed.  There are only two options: a sweeping change in software patent legislation written by multiple parties working in concert with software industry leaders to fix an abomination that shouldn't exist; ...or just save time and money by killing the whole software patent system.

Ending the System
It wouldn't be that bad to get rid of software patents.  Europe does not allow software patents (the European Patent Office has allowed some patents involving software, but "programs for computers" have not been regarded as patentable inventions since 1973), and they have a bustling software industry.

There would be many benefits to dismantling the software patent system.  First, there would no longer be any software patent trolls.  Second, software engineers would probably produce more free and open source software (FOSS) since they would no longer have to worry about securing software patents that could be used in defense.  This would create the conditions for a new software startup boom.  Without the fear of patent lawsuits and given new FOSS tools, starting a small software company would be less risky.  Even larger software companies would benefit, since they wouldn't have to waste resources on expensive legal fights.  Society would get more cool tech stuff released more often.  This increased innovation would probably have a positive effect on the American economy.

Let's not forget that there are already intellectual property protections for software.  Copyright will be the primary protection for software.  There are also trade secrets.  And lastly, there's the profit motive and the notoriety of releasing first.  In this fast-paced industry, whoever comes out with a cool new concept first will profit from having a working product in stores while other companies try to work out the kinks in their labs.

Reforming the System
I'm calling for the end software patents in the US and elsewhere.  However, if we cannot end the software patent system, we should reform it at the very least.   My list of reforms:

1. Software patents must be specific.
   No more language about "the machine", "network web sites", "memory bank portions" and other archaic language unused since the days of vacuum tubes for the sole purpose of obfuscation.  Requiring clear and current language without extraneous implementation details will make patent application, processing, and litigation go a lot faster and easier.
2. Software patents must be used.
   If you are the owner of the software patent, you must be using the invention to actually create a product, or you must license the patent at a reasonable price.  Waiting for someone to violate your unused patent so you can extort them is unethical and it should be illegal.
3. Software patents should have a short lifespan.
   Twenty years is too long to hold a monopoly on a technology in the software industry.  Bezos and O'Reilly suggested 3-5 years, which is much more reasonable.
4. The US Patent and Trademark Office must remove their bad patents.
   The Office must go through their existing patent database and get rid of duplicate patents and other invalid patents.  The USPTO is mostly to blame for this fiasco and they should fix this.  Otherwise, how can inventors tell what inventions to avoid using and applying for?

By reforming software patents--or better yet, getting rid of them altogether--, we can fix the problems in the industry before any more damage is caused.  When we do, society will reap the benefits.

Policy: We Must Abolish (or Reform) the Software Patent System

(Our Broken Software Patent System, Part 3 of 3)

We must abolish the software patent system.

Yeah, you heard me.  Scrap it.  Get rid of the whole thing.

I've already explained in utter detail why the system is very, very broken, and why there's no hope that it will ever be fixed.  There are only two options: a sweeping change in software patent legislation written by multiple parties working in concert with software industry leaders to fix an abomination that shouldn't exist; ...or just save time and money by killing the whole software patent system.

Ending the System
It wouldn't be bad to get rid of software patents.  Europe does not allow software patents*, and they have a bustling software industry.

There would be many benefits to dismantling the software patent system.  First, there would no longer be any software patent trolls.  Companies that abuse the legal system to prey on small software businesses would cease to exist.  Secondly, software engineers would probably produce more free and open source software (FOSS) since they would no longer have to worry about securing software patents that could be used in defense.  This would create the conditions for a new software startup boom.  Without the fear of patent lawsuits from patent trolls or even large legit software companies, and given new FOSS tools, starting a small software company would be a less risky concept.  As for larger software companies, abolishing software patents would make these companies more agile, since they wouldn't have to waste resources on expensive legal fights.  Society would get more cool tech stuff released more often.  All of this increased innovation would probably have a positive effect on the American economy.

Let's not forget that there are already intellectual property protections for software.  Copyright will be the primary protection for software.  No one can steal a software engineer's or software company's actual code.  There are also trade secrets.   Just like the Coca-Cola Company keeps their Coke recipe a trade secret, a software company can keep its compression algorithm secret if it so chooses.  And lastly, there's the profit motive and the notoriety of releasing first.  In this fast-paced industry, whoever comes out with a cool new concept first will profit from having a working product in stores while other companies try to work out the kinks in their labs.

I join Richard Stallman and the Free Software Foundation in calling to end software patents in the US and elsewhere.  However, if we cannot end the software patent system, we should reform it at the very least.

Reforming the System
The list of people that want to just reform the software patent system is longer than the end-patents-list (Jeff Bezos of Amazon and Tim O'Reilly of O'Reilly Media, the Electronic Frontier Foundation (EFF), Nilay Patel of The Verge, David Drummond of Google, most of the US House of Representatives, etc.) so reform might be an easier goal.

I've co-opted some people's ideas on reform and come up with a few ideas of my own.  My list of reforms that would fix the software patent system are as follows:

1. Software patents must be specific.
   No more language about "the machine", "network web sites", "memory bank portions" and other archaic language unused since the days of vacuum tubes for the sole purpose of obfuscation.  These things are "the computer", "websites", and maybe "areas in memory" (?) respectively.  (Though, really, hardware usually has no place in a software patent.  Usually, hardware is only mentioned as part of a patent to lend credence to the notion that it is an "invention.")  Requiring clear and current language without extraneous implementation details will make patent application, processing, and litigation go a lot faster and easier.
2. Software patents must be used.
   If you are the owner of the software patent, you must be using the invention to actually create a product, or you must license the patent at a reasonable price.  Waiting for someone to violate your unused patent so you can extort them is unethical and it should be illegal.
3. Software patents should have a short lifespan.
   Twenty years is too long to hold a monopoly on a technology in the software industry.  Bezos and O'Reilly suggested 3-5 years, which is much more reasonable.  The EFF also said a max of 5 years.
4. The US Patent and Trademark Office must remove bad patents from their database.
   The Office must go through their existing patent database and get rid of duplicate patents and other invalid.  The USPTO is mostly to blame for this fiasco and they should fix this.  Otherwise, how can inventors tell what inventions to avoid using and applying for?

With reforms such as these, the purpose of software patents would be restored.  Software inventions would be protected from stealing, but it would be easy for inventors to tell what patents existed and whether an idea was new or not.  The title of most innovative tech company would no longer depend on who has the biggest legal team.  Patent trolls would have a hard time existing.  And when the occasional invalid patent was granted, the owner would only have an illegal advantage for a short period of time.

In summation, we Americans must reform software patents--or better yet, getting rid of them altogether.  We can fix the problems in the industry before any more damage is caused.  When we do, society will reap the benefits.

* The European Patent Office has allowed some patents involving software, but "programs for computers" have not been regarded as patentable inventions since 1973.

Policy: The Software Patent System Will Always Be Broken

(Our Broken Software Patent System, Part 2 of 3)

The software patent system is broken.  You know it, I know it, most software engineers know it, and even the government is vaguely aware that something is wrong.  But someone will fix it, right?

Not likely.  While I sincerely hope that with enough reform, the patent office can fix this mess of a system, I believe that the software patent system will always be broken.  Let me explain.

Reforming the System Is Hard
Changing such a huge system to be efficient and coherent would be hard.  The software patent system is at the intersection of law and software engineering, an area few people understand well.  As such, it can be difficult to solve its problems or even describe what the problems are.

There's a lot of stakeholders in the current system that need to be considered.  For example, can software patents be reformed while leaving hardware patents alone?  How do you convince hundreds or thousands of lawyers, judges and programmers to change what they've been doing for decades?  Is it possible to banish patent trolls without screwing over regular inventors, especially those that don't know how to sell their invention?

Changing the system will require a lot of precise, sweeping changes.  It's possible, but incredibly difficult.  So who's going to do it?

The Government Won't Fix the System
Firstly, the United States Patent and Trademark Office is unlikely to fix the software patent system.  For one, they are overburdened with work already.  In 2011, Chief Judge Paul R. Michel (retired) noted that, "Inventors must now wait three years, on average, and often longer. Thomas Edison had to wait less than three months. In my view, eighteen months should by the longest time anyone must wait."  He blamed the problem on lack of funding, which is needed for "thousands" of more patent examiners and better IT systems.

Whatever the root cause, the USPTO has too many patents to process and too little time to process them.  I suspect that this extra amount of work has lead patent examiners to approve lower-quality patents.  Patents that would not have been approved in less-busy times are now being approved.  A recent study also suggests that the patent office has lowered standards to cope with the huge backlog of pending patent applications.  The USPTO cannot fix the problem with duplicate and obvious patents being approved because they are too busy to examine applications carefully.

Perhaps the USPTO doesn't care about reforming the software patent system.  Surely, it would lessen their workload if the system was more efficient because there would be less patents to approve and less patent lawsuits to handle.  However, it could make their jobs harder by requiring patent officers to go through lots of existing invalid patents in the system.  But even if the USPTO doesn't look back at already approved patents, patent officers will have a harder job if patent applications require higher scrutiny instead of the rubber stamping the patent office does now.  "Rubber stamp" may seem like a bit of hyperbole, but the acceptance rate of patent applications is around 90%, when you don't count refiled applications as separate applications (see graph below).  If you try and try again, your application will be accepted, it seems.

The patent allowance rate has skyrocketed in recent years. Source: Ars Technica 

Like many inefficient government agencies, the problem may be with bureaucrats.  A political reason is needed to enact any major reform.  Until software patent reform becomes an election issue, we shouldn't expect much change from the USPTO.

Congress or the President could fix the system but, as I said above, patent reform is not a sexy issue and is unlikely to get the attention it deserves.  Furthermore, I doubt the President or Congress understand this thoroughly complex problem.  (Note that the House surprisingly passed the Innovation Act, which was a start, but the Senate shut it down earlier this year for some reason.)

The Industry Won't Fix the System
I doubt that software companies will fix the system.  Large software companies already have purchased hundreds or thousands of patents and are immune to patent trolls.  They can even troll smaller companies with their large portfolios of patents.  Small software companies are feel the most pain from this broken system, but they don't have the lobbyists to effect change in Washington.

Patent lawyers, whether they work for the government as examiners and judges or for companies as patent attorneys, have even less incentive to change the patent system.  They have become a hot commodity in recent times.  The broken patent system is their livelihood, and a lucrative one at that.

The System is Intrinsically Unfixable
Another reason I believe the software patent system will always be broken is because the idea of software patents is (pardon the pun) patently absurd.  Software is unique and is inherently unpatentable.  That's just one more reason software patents will never be "fixed."

I know this is a bold claim, but I'm serious.  Let's break it down.

Firstly, software is a fast-paced industry.  The next big thing is often deprecated in a short amount of time.  Let's look at smartphones for an example.  Although 3G wasn't new, 3G data was a huge selling point for the iPhone 3G in July 2008.  Two years later, HTC released the EVO 4G, the first 4G smartphone in the US.  However, that phone used WiMAX networking for its 4G capability, and WiMAX was declared dead as of 2013 or 2014.  All major US networks now use LTE for 4G data.  In less than 6 years, the way smartphones sent data over mobile networks changed multiple times.  Yet software patents last 20 years.

Think about how long 20 years is in terms of software.  It's 2014 (as of press time here at Omari's Tech Blog).  In 1994, Windows 3.1 was the most popular desktop operating system.  Nobody you knew had a cell phone, though I knew a few lucky families with a car phone.  You got on the Internet by dialing into one of AOL's servers.  My, how things have changed.

Twenty years is several lifetimes in software years.  This means that software companies must license any important patented technology if they are to survive, and that license may not priced reasonably or even available to license at all.  Twenty years is just way too long to give exclusive rights to a software invention when you consider how fast the industry moves.

A second issue is that patents aren't as necessary for software as they are for hardware.  I understand the need for protecting hardware.  Inventing new mouse traps or lawnmowers or killer robots requires not just time, but materials.  That first mouse trap may not work correctly, so you need to create lots of physical prototypes until you get it right.  That requires real materials, like wood and metal.  And probably more than a few mice.

"Inventing" software requires none of that.  All you need is one basic computer to program on and you can create endless prototypes without worrying about materials or trial runs in harsh conditions, unless you're trying to program for some specific device.  Even then, there are emulators that allow you to program apps for smartphones and vending machines, etc. without actually purchasing the device the software will end up on.  Technically, you don't even need the computer.

Lastly, the complexity of software causes difficulty in deciding their patent eligibility.  In Patent Failure: How Judges, Bureaucrats, and Lawyers Put Innovators at Risk by Bessen and Meurer, they describe how software's complexity hinders its patentability: "It is possible, however, that features of software technology make it particularly susceptible to the patenting of obvious ideas, especially given the legal doctrines of non-obviousness developed by the Federal Circuit."  Because software patents are quite susceptible to obvious patents, patent officers and patent judges have a much harder job.

Software is different.  Software is special.  Software might even be unpatentable.  But even if it isn't, the software patent system will always be broken because no one can fix it.

That's why we must abolish software patents.

Continued in We Must Abolish (or Reform) the Software Patent System.

Policy: The Software Patent System Is Broken

(Our Broken Software Patent System, Part 1 of 3. Or you can read the short version)

The American patent system is completely broken, at least when it comes to software patents. Billion-dollar software companies are suing each other over minor pieces of code, patent trolls run rampant, and consumers are losing out as the original purpose of software patents have been lost. In this three-part article, I'll first convince you that the software patent system is broken in the US, then that the system shows no signs of changing, and finally I'll discuss what we can do about it.

Note that this article is about software patents in particular. The US patent system may work better for other industries; I don't know. My research has been confined mostly to software patents.

The Point of Software Patents

Let's first talk about the point of software patents. Patents are a form of intellectual property, like copyright. Unlike copyright, patents cover inventions instead of creative works and last for a shorter time (20 years compared to copyright's roughly 100 years). The purpose of a patent is laid down in the constitutional clause that gives Congress the power "[t]o promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries" (Article I, Section 8, Clause 8).

The idea behind patents is great. If you spend years inventing something, perhaps building a better mousetrap, then someone shouldn't be able to see your mousetrap in a store, steal your idea and sell the same mousetrap while bypassing all the hard work you did refining the improved mousetrap.  Or worse, they could see your mousetrap in your secret lab while you are still refining it, steal your idea and beat you to market.  With patents, you must reveal your invention publicly, but then you have the exclusive rights to that invention for 20 years.

However, there are limits. You can't patent just anything, someone would patent the wheel and sue all the car manufacturers.  Patents must be a patentable thing (a process, machine, "[article] of manufacture," and composition of matter), and they must be  new, useful and nonobvious. "New" means you can't patent the wheel; it's already been invented. "Useful" means the invention has to actually do something. "Nonobvious" means you can't just slightly tweak someone else's invention; if there's already a patent on a standard pencil, the patent office won't grant you a patent on a slightly smaller pencil.  That's just an obvious extension of an existing invention.

Applying these principles to software is pretty new. Software patents only became legal in the US in the 70's and 80's. The courts are still trying to figure it out. In eBay Inc. v. MercExchange, L.L.C. (2006), Justice Kennedy and other justices questioned the wisdom of permitting injunctions in support of "the burgeoning number of patents over business methods," because of their "potential vagueness and suspect validity" in some cases.

Lots of Existing Patents Are Invalid

Non-New Patents
Now that we've discussed how software patents are supposed to work, what's the problem? Well, one problem is that people are patenting things they shouldn't be able to patent. Remember that all patents must be new, useful and nonobvious.  Well, people are patenting existing software inventions.

Two excellent sources of information about our broken software patent system are the This American Life episodes " When Patents Attack!" and " When Patents Attack ...Part Two". I cannot recommend these episodes of This American Life highly enough. You can listen to the first one below. But to get to my point, during Part One the journalists from This American Life (TAL) talked to David Martin, the founder of M-CAM. M-CAM is hired by governments, banks, and other businesses to assess patent quality. M-CAM uses special software to search through all existing software patents to find patents that are essentially the same. Ideally, each patent should be unique. However, sometimes the US Patent and Trademark Office (USPTO) grants patents for things that have already been invented and patented. During the TAL episode, Martin looked up how many matching patents there were for one specific software patent. There were 5,303 matching patents.

"We thought that would be an anomaly. And then we were told, oh no, it's not an anomaly. That happens. [....]And as I've testified in Congress, that happens about 30% of the time in US patents."
- David Martin, (emphasis added)

The specific software patent that Martin was looking up with TAL was Patent 5771354 "Internet online backup system provides remote storage for customers using IDs and passwords which were interactively established when signing up for backup services". According to the owners, Intellectual Ventures, it covers upgrading software on your home computer over the Internet. For example, "when you turn on your computer and a little box pops up and says, 'Click here to upgrade to the newest version of iTunes'". When TAL looked at the text of the patent it seemed like it did a lot more than that. Having looked at it myself, I'd agree. It appears to cover doing any sort of data backup over the Internet, using an ID and password.

Drawing from Patent 5771354 showing
how all computer networks work

Didn't online backup solutions exist before 1999, when this patent was filed? Apparently. The Wikipedia article for cloud storage talks about AT&T's PersonaLink Services in 1994. This was a service for storing your PDA data. That sounds like an existing invention to me. But let's ignore that example for now. Martin's software found Patent 6003044 and Patent 5933653, which also cover backing up data remotely.  This invention has been patented many times over.  When TAL's Alex Blumberg expressed incredulity that 30% of US patents were redundant, Martin pointed out there was a patent on toast.

Patent 6080436 "Bread refreshing method" was issued in 2000.  It patents toast.  Don't believe me?  Go read it for yourself.  Granted, it isn't a software patent, but it shows the flaws of our patent system.

It should be clear now that the USPTO allows inventors to patent inventions that have already been invented, breaking the requirement that all patents be new.  There are duplicate patents abound.  Furthermore, I'd argue that even if an inventor receives the patent on something, it doesn't mean he or she invented it.  That person may have just been the first to file a patent.  Filing a patent is an expensive, time-consuming process.  According to the USPTO, it takes about 2 years for a patent to be processed.  The cost of filing a software patent is around $10,000 (UpCounsel, Richards Patent Law, IPWatchdog) when including legal fees, which might be a drop in the bucket for a major corporation but is expensive for a small startup.  Because of these barriers to getting a software patent, the actual inventor may not be the first to file a patent on a particular invention.

Obvious Patents
So software patents may be patented and re-patented.  But even "original", previously unseen inventions may have problems.  For example, they might be obvious extensions of existing patents.  As I said above, you shouldn't be able to patent a slightly smaller pencil.  The pencil has already been invented, so taking an obvious idea such as making slight tweaks to the size or color is not patentable.  Sure, that idea might be "new", but inventions must also be nonobvious.  But obvious software inventions are being patented every day.

As a software engineer and a person who is skilled in the field, I would describe Amazon's 1-Click patent as fairly obvious.  In short, it describes the ability to save your credit card information in a website so that you can purchase items with only one mouseclick.  I am not the only who believes this patent to be obvious.  As one blog pointed out, it's a "fairly broad concept" that the European Patent Office denied a patent to because it was "obvious to a skilled person".  To give another example, this patent caused the Free Software Foundation to boycott Amazon for a short time on what it called "an important and obvious idea for E-commerce".

There are other examples of patents on obvious "inventions."  Richard Stallman, a software engineer who is famous for his work on GNU, Emacs, and other free software, decries the obviousness of Patent 5963916, applied for in October 1996 in his text, "The Anatomy of a Trivial Patent".  Patent 5963916 ("Network apparatus and method for preview of music products and compilation of market data") covers listening to a preview clip of music on the Internet.  After posting a snippet of the patent, Stallman writes, "That sure looks like a complex system, right? Surely it took a real clever guy to think of this? No, but it took cleverness to make it seem so complex. Let's analyze where the complexity comes from[...]"  Stallman then proceeds to analyze each line in the first portion of the patent to point out how each aspect of the idea was already existing or, at least, very obvious at the time:

Now look at a subsequent claim: 

3. The method of claim 1 wherein the central memory device comprises a plurality of compact disc-read only memory (CD-ROMs). 

What they are saying here is, "Even if you don't think that claim 1 is really an invention, using CD-ROMs to store the data makes it an invention for sure. An average system designer would never have thought of storing data on a CD."

In case it's not clear, Stallman is being extremely sarcastic. Even back in 1996, CDs were commonly used for storing data.  This is one of the patents that Stallman calls "laughably obvious".  The problem is that the overly complex language of patents obscures the obviousness of the ideas.

This is a huge problem.  Lots of software patents in the US are actually invalid because they are obvious or already patented.  If David Martin's numbers are to be believed, there are hundreds of thousands of invalid software patents in the system.  But invalidating a patent means spending lots of time (years) and money (millions of dollars) in court.  Because of this, the original purpose of software patents--promoting progress--has been lost.

Software Patents Aren't Serving Their Purpose

The first problem with software patents is the barrier to entry.  That is, the money and time spent in getting a patent may create a burden for startups and solo software engineers.  As mentioned above, it can take around 2 years and $10,000 to get a software patent.  This fact alone may dissuade programmers from trying to create innovative new software that the public would benefit from.  However, this is a small problem compared with other software patent issues.

One of the most insidious problems with software patents is the menace of patent trolls.

Patent Trolls

Alaska Robotics - "Patent Trolls"

According to the most popular definition, a patent troll (also called a patent assertion entity) is a company that obtains patents--usually through buying them--and, instead of making products based on those patents, waits for another company to violate their patents, and then forces that company to pay licensing fees to use that patent.

Let's take the example used in the introduction of the "When Patents Attack!" This American Life podcast.  Since 1999, Jeff Kelling has been working for FotoTime, a small company that hosts a photo sharing website.  This was before major photo sharing sites like Flickr, although FotoTime wasn't the first photo-sharing website.  In May 2008, they received a letter from FotoMedia (not to be confused with FotoTime) that said FotoTime was in violation of 3 patents.  FotoTime was told to contact FotoMedia to arrange payment, or FotoMedia would take them to court.  Jeff's team looked up the lawsuit and noticed that FotoMedia had sent the letter to 130 other companies including Yahoo (Flickr), Shutterfly, Photobucket, and other companies, big and small.

There were a lot of reasons this was weird.  One was that FotoTime hadn't realized that they were violating any patents.  Whatever patents were being violated, FotoTime had evidently come up with the same idea themselves, without reading FotoMedia's patent or copying some FotoMedia product.  Another weird thing was that FotoMedia wasn't a competitor to FotoTime.  FotoMedia didn't have a photo sharing website.  Then when Kelling called FotoMedia to ask them which patents FotoTime was violating, FotoMedia wouldn't tell them.  Kelling said, "They said they wouldn't answer that until we got into court."

Kelling learned that fighting the patent would cost an estimated $2 to $5 million, which was "more than [FotoTime] could handle".  FotoTime settled with FotoMedia.  As part of the settlement, FotoTime is forbidden from saying how much they had to pay FotoMedia.

This is what patent trolls do.  They purchase a patent that is somewhat vague or perhaps even invalid, and instead of making some technology that uses the patent, they threaten to sue companies they think are using the patent.  They might try to sue hundreds of companies, as in the case of FotoMedia.  Some companies will pay them a fee rather than spend millions of dollars fighting the patent in court.  The patent trolls will then use that money to purchase more patents and sue more people, ad infinitum.

This isn't a business.  This is, as venture capitalist Chris Sacca described such practices on This American Life, "a mafia-style shakedown."

And patent trolls are growing bolder.  According to a Presidential study, the number of lawsuits brought by patent trolls more than doubled from 2010 to 2012, and these lawsuits accounted for 62% of all patent lawsuits in America in 2012.  Victims of patent trolls paid $29 billion in 2011.  Now in 2014, these numbers are probably higher.

The Damage from Patent Trolls
This patent trolling kills innovation in a few ways.  One problem is that software companies must spend money on legal fees instead of growing their technology.  It's impossible to know whether your company will be violating a patent or whether a patent troll will target your company, so it's now important to have a good legal team to either negotiate a settlement or fight the patent lawsuit if and when a troll sues your company.

Some startups may not be able to pay the legal fees from a patent lawsuit and may go under.  Jeff Kelling of FotoTime said that "The settlement they [FotoMedia] wanted to get was just enough to put us in danger, but not to close us [...]"  It seems that lawsuit came close to shutting down FotoTime.

Patent trolling can even create a chilling effect, causing programmers good ideas to never pursue their startup for fear of being sued by a patent troll.

Software patents no longer promote progress, if they ever did.  Now, software patents stifle innovation.  It's impossible to know whether a company is actually violating a patent because the patent office is a confusing mess, containing vague and duplicate patents.  And so any software company with a good idea can be sued at any time, by a patent troll claiming that software company is violating its patents.  Sure, the current software patent system is great for patent trolls, who create nothing and provide no benefit to society.  And this is the exact opposite of the purpose of the software patent system.

The system needs fixing.

Continued in The Software Patent System Will Always Be Broken

---

This American Life: When Patents Attack!

Software Engineering: Good Reads

I'm not an avid book reader, so I feel that my book suggestions should be taken seriously, since there are so few books I can really recommend.  I think there are a few software-engineering-related books that every good programmer should have on their shelf.  I will list these books, roughly in order of importance.  I've also listed each book's latest edition (that I know of).

The C Programming Language, 2nd Edition by Brian W. Kernighan and Dennis M. Ritchie

The C bible. C is still an important language for many programmers to learn, and this is the book to use to learn it.  Never before or since has a programming language had a textbook so thorough.  I only wish that Java or C++ had a similar textbook that I could recommend as highly.  Maybe it's because C is a small language, but this book works well whether you're learning C for the first time, or you just need a reference.  The only downside is that the latest version of this book covers ANSI C, instead of either the newer revisions, C99 and C11.  For that reason, if you're using a C99 or C11 compiler, this book is somewhat deprecated. C99 made a lot of important changes to the language.  However, the book is still a good starting point if you don't know any C (or, again, if you're using an older compiler).

Introduction to Algorithms, 3rd Edition by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein

This book contains all the information you need to know about algorithms and data structures, including their pseudocode implementations and computational complexity.  I suggest it to everyone who is applying to Google as a software engineer.  The only issue is that it is too complete, and contains a lot of extraneous information.  It's not a book you read cover to cover.  Also, I'm not a big fan of their "pseudocode."  A more Java-like or Python-like language would be easier to read.  As a software engineer for any company that relies on speed for computing large amounts of data, you will need to know the most efficient way to solve your problem.  This book will help you get there.

Effective Java by Joshua Block

That's great that you can write a one-line method to sort an array.  Now, graduate from a programmer to a software engineer by learning why that is awful.  Effective Java tells readers about readability and other important issues that come up with writing code in a work environment.  Basically, it's a collection of tips for writing readable, maintainable Java code.  Do you swallow InterruptedExceptions, that is, catch them and then simply throw them away?  If so, Joshua Block will tell you why you're breaking his heart and the heart of everyone around you.  (For those who just want the answer, read this. Or the simple answer is that you may prevent a program from being killed when it needs to die.)

Software Project Survival Guide by Steve McConnell

This book is written more for managers and team leads, but is useful to all engineers.  It describes in detail the basic ideas and reasoning behind a waterfall software engineering process.  A lot of you may be using agile or scrum, but you can still incorporate most of the ideas in this book in your work process.  Testing, maintainability, requirements, tracking... this book has all you need to turn your cowboy coders into seasoned engineers.  Process, process, process.

Team Geek by Brian W. Fitzpatrick and Ben Collins-Sussman

This book written by two Google engineers seems to be written more for team leads, but, again, is useful to any software engineer or manager of software engineers.  It's all about the non-technical side of software engineering; the human element.  For example, they cover dealing with "poisonous" coworkers, building a strong team, how to have efficient meetings, and how to communicate and collaborate well.  This is the only book I didn't have to read for school or work that I'm recommending.  I think it's important because even a group of smart, trained software engineers can have interpersonal issues or leadership issues, and this book tries to train people to alleviate those issues.