"They came for the open source software developers, but I did not speak out because I am not an open source software developer.
Then they came for the indie software developers, but I did not speak out because I am not an indie software developer.
Then they came for the startup software developers, but I did not speak out because I am not a startup software developer. Actually I'm not a software developer of any kind. I do have a cousin who's a software developer at BigCorpEnterprise Limited, but they don't seem to be coming for him.
And then they came for some of the open source software developers and indie software developers and startup software developers that they missed the first time.
And then they didn't come for anyone else. So that's OK then. It's not like those software developers got put in prison or anything. I mean, if they're so clever that they "accidentally" re-invent a patented software invention every time they write a hundred lines of code, then they must be clever enough to get a job at BigCorpEnterprise Limited, so what are they complaining about?."
The Evilness of Software Patents
The evilness of software patents is obvious to many software developers, especially to developers interested in open source, or small-time "indie" developers, or those in startups.
However, according to relativistic theories of morality, something is evil only if most people think it is evil. (Most believers in absolute morality believe in the Bible, or some similar book, but unfortunately the Bible doesn't say anything about software patents, so I'm going to go with relativistic morality here.)
Unfortunately, most people aren't software developers. So most people do not think of software patents as evil (if indeed they've even heard of "software patents", or know what they are). From which it unfortunately follows that software patents are not evil.
Those of us who keenly feel the evilness of software patents can attempt to remedy this problem by telling the rest of the world that software patents are evil.
The problem with this approach is that you become just another person complaining about one of those things that other people complain about, like Al Gore complaining about Global Warming, or a Wall Street Occupier complaining about Wall Street.
Telling other people that something is evil, tells them that you think it is evil, but that is not the same as making those other people feel that it is evil.
A Plan To Increase Evilness
Given that only software developers feel the intrinsic evilness of software patents, it follows that the only way to show people that software patents really are evil is to turn more people into software developers. Ideally we could turn everyone into software developers, but that might be a bit much of an ask. But if we could turn even 20% of the world's population into software developers, then that would be 20% who understand why software patents are evil. For the remaining 80%, it's much harder to ignore other people telling you that something is evil, if that number of people consists of 20% of the people that you know.
The Difficulty of Software Development
Unfortunately, software development is a difficult thing, and the problem of making software development less difficult is itself a very difficult problem.
Much progress has been made. C is easier to program in than assembler, Java is easier to program in than C, and languages like Python and Ruby are easier to program in than Java. Also, these days there are better development tools available to everyone for free, including text editors, IDEs and source control applications like Git.
But even with all this improved programming technology, we seem to have hit a plateau. There is some limit to how easy development can be made to be, and that it seems unlikely that we can invent any new programming language which will make it easy enough for all the people who aren't yet programmers to programming.
There have been attempts in other directions, like visual programming, and CASE, and "English-like" programming languages such as Applescript and Rebol. But none of those have got us anywhere much.
We could just resign ourselves to the fact that computer programming has a certain minimum level of difficulty, and it should be left to those sufficiently skilful and knowledgeable to do it.
But the problem of software patents adds a certain urgency. If we want everyone to know what it feels like to be threatened by software patents, we have to make it possible for everyone to develop software. We have to make it easier for everyone to become a software developer capable of implementing their own original ideas, so that they can come to understand how their own work to implement their own idea can be defined by the patent system to be an infringement (and therefore "theft") of someone else's idea.
We have to redouble our efforts to make software development easier, even if that means we put more effort into making software development easier than we put into software development itself.
Some Ideas About Making Software Development Easier
Unfortunately I don't have a magic wand to make software development easier. But I do think there are opportunities to exploit the power of computers and Internet to make some software development much easier than it is now.
So here are my ideas, which I modestly claim to be somewhat "outside the box":
Software development is hard because understanding software is hard, especially if you didn't write it.
Writing useful software usually requires the effort of more than one person. But contributing to a software project is hard, because understanding existing software (which is something you have to do before you can start improving it) is hard.
Which is why my next ideas concentrate on how to solve the problem of making it easier to understand existing code.
We need to stop assuming that there is some right amount of documentation and commenting.
Steve Yegge tells us that only total noobs put too many comments in their code.
Total noobs put that much documentation into their code because they find it hard to understand code without that much explanation. But if we want to make existing source code bases accessible to as many people as possible (most of whom are "total noobs"), then we actually require comment overkill.
This is part of the motivation behind my concept of Extreme Documentation, as explained by myself here (which gives Extreme "Negative" Code Documentation as an example of a specific type of Extreme Documentation, but which is not necessarily the only type of Extreme Documentation that we can or should add to our code).
My extreme-doc project is work-in-progress which supports what might be called "Un-Intrusive" Extreme Documentation, where "normal" and "extremely documented" versions of source code are to be maintained in parallel (and the extreme-doc project will include special merge tools to help keep the parallel versions in sync).
More work should go into making code accessible than goes into writing it in the first place.
Consider the sheer number of people in the world. All the world's open source software is written by a tiny percentage of people in the world, especially if we only count software that is heavily used by other people. If we could get ten times that number of people to contribute to the process of making existing source code bases more accessible, then we could put some even large number of people in a position where they could make some contribution to those same code bases.
The fundamental problem of source code comprehension is the gap between programming languages and natural languages.
We know that English sucks as a programming language, because implementing English as a programming language is equivalent to solving the AI problem. Which is a hard problem.
However, translating code into English is somewhat easier, and we solve this problem in a limited fashion for individual items of code all the time. For example:
- Comments are English translations of the code that they describe.
- Debugging log statements are runtime translations of information about the state or actions of an application into English.
One plan is to attempt to translate all code in a given programming language into English, using descriptions for individual objects combined with generic rules for translating the control structures of that language. My guess is that the results of this will be obviously clumsy, and probably not that much easier to understand than the original code.
A second plan is to create translation of intermediate generality based on some kind of pattern matching: less general than trying to specify a translation of all possible programs into English, but more general than individually commenting and/or logging every individual specific line of code. This type of translation could focus on specifying translations of specific coding idioms.