The Big Idea. Our company is pushing a big Thought Leadership initiative. They want us to come up with innovative new ideas, and leverage them into the market. (Did I really just say "leverage"?) There's even a prize for the best idea that's proposed within the next few months: a trip for two to Byron Bay.
Right about the time they announced this, an awesome new idea struck me. The particulars of it are technical (they're described at the end), but in short it would mean that at the very least our company could be producing much more reliable software. Conceivably the Idea would grow to become the ultimate new must-have testing tool. And further afield, I thought it might have the chance to change the way programming itself is done.
I thought about it for weeks -- in bed, on the toilet, on the tram. It would be difficult to write, but not beyond my ability. I had visions of leading a group of employees to develop and expand it, and to apply it to our existing applications. Or even to apply it to existing software (such as the Java Virtual Machine itself).
It would be hailed by one and all. And I would be feeling all smug and heroic while Marjorie and I relaxed up in Byron Bay, margaritas in hand.
The Idea was sitting out there, ripe and unplucked. I looked around, and could find no one else who had done it before. This was it. My big moment.
And so. Just before I started bearing down to work on a proof of concept, I decided to give one last look around to make sure it hadn't been done before. And as you've probably guessed by now, I found a product that does exactly what I had been thinking of, and then some.
Rather dismayed, I downloaded and ran it against our current project, and it found a lot of bugs. They did a great job with it, but the fact that it has not taken the programming world by storm is of some small consolation.
[Geeky technical description: I'll talk about how it applies to the Java programming language, but there's no reason why it couldn't be applied elsewhere. It occurred to me that you could, through code analysis, determine places in the code where null pointer exceptions would occur, simply by tracking variables as having a value of "null", "not null", or "maybe null". Methods would be tracked as returning the same possible values. So, it is quite possible to determine, for every pointer dereference, whether a null pointer exception was even possible. A program that passed such a scan with no possible null pointer dereferences would be guaranteed never to crash that way. And that is one of the most common ways for a program to crash.
After considering that for a while, it occurred to me that other unchecked exceptions, such as array index out of bounds and class cast exceptions, could be scanned for in a similar manner.
The program I found that does it is JLint. It finds many, many other kinds of bugs as well. You can integrate into the Eclipse API using this plugin, just like I was planning to do with my idea.
I don't know why it's not used more widely. Probably because it was done as a research project and has no advertising dollars behind it.]
