Firefox killer addon idea

If you're like me you probably have a bunch of web sites you like to read regularly. Some I want to see every day. Others once a week. Some maybe just once every three months.

Of course solutions to this sort of thing already exist. RSS is the obvious one. Anybody can use a Feed Reeder such as http://google.com/reader to look at what's changed on a bunch of web pages.

Nice, but it's not quite what I want. If I normally look at a site once a week I don't want to be directed to it each time something changes on the front page.

Instead imagine a comment on important bookmarks that indicate how often you want to view a web page, such as 1 day, 2 weeks etc. The browser keeps track of page visit. So all I want to do is press one hot key (maybe the space bar) and have Firefox jump to my next page. It would be simple to have all of these special bookmarks in a priority order based on the last viewed time and the desired frequency.

One key press, and you're looking at the page you'd next want to see. Maybe even arranged as a three or four tabs loading in advance.

Now that'd be a killer addon.

I admit I started looking around trying to figure out how to write such an addon. But I just can't seem to find an API to handle bookmarks. Any addon gurus out there want to take a crack at this?

Now that's a fun game

This guy is singing the praises of a fantastic arcade game. And he's completely right. It's called Grid Wars 2, and it's awesome. Gameplay perfection.

Will this cartoon change the face of software?

Stevey's rather well-known post about his views on Agile development may well be remember more for the Far Side cartoon and Java's approach to manifest typing than anything he says about Agile (he must have met some scary Agile people). My own (limited) experience with Agile has been more positive.

But (in this context) that cartoon is so memorable, so visceral, that it is bound to be quoted in any future debate about dynamic versus manifest typing. So far the debate has seemed fairly evenly balanced. Although I'm a fan of the dynamic languages such as Python, Ruby and Lisp, they haven't made convincing inroads against the dependable Algol-like mainstream just yet.

But now even manifest advocate must argue with that cartoon swirling around in the background.

List<ProManifestArguments> proManifestArguments = new ArrayList<ProManifestArguments>()

It's a mouthful.

(Too Much) Configuration Considered Harmful

Configurability is a desirable thing for software. It gives us the flexibility to deploy into different environments, and every now and then to fix a problem without having to touch the code. Environments like the Spring Framework revolve around configuration, and can be great for managing a project with various interacting modules.

But it's not a panacea.

As the amount of configuration grows it begins to overwhelm people's ability to deal with it. I once worked on a very large software project (staff in the three digits) and it was enormously configurable. Every aspect of it could be configured.

It never seemed to run. There was always something wrong with the configuration.

In the same sense I'm doubtful about the value of moving a lot of business logic into any kind of rules engine. The top ten most valuable rules, fine. But after that we have diminishing returns for ever increasing complexity. And that's exactly what we should be avoiding in software.

Successfully Denying Reality

Denying reality is an all too common human failing. Why do people continue to do it? Because it often works.

When I see various forms of I.T. madness occurring in a big company I often wonder: "How can this continue? It's costing them so much." The examples seem endless. Using a product beset with issues and offering dubious value just because a big name vendor sells it. The inability to set up an email account in less than two weeks. The manager who won't accept a realistic estimate and pushes for a quick finish so that everybody cuts corners, and the resulting mess takes four times longer to clean up.

So why does it continue? Sadly, because it's successful. Often the people most at fault are those who are able to shift blame to others, escape oversight and make endless promises of imminent future improvements. The company shareholders are paying the price, not the individuals concerned.

Again this is an aspect of human nature not restricted to I.T.; we see it frequently in politics. And it crops up in personal life. We put off that trip to the dentist or eat that extra helping of dessert. Nitpick the evidence for Global Warming. Claim that some disastrous policy is actually working. With no consequences for a long time.

Perhaps the clearest example of all is religion. Believing in a god doesn't seem to be that much of a practical handicap. Billions do it and lead what seems like a fulfilling life despite their break from reality. Their reward in the next life will be denied, but that cannot be discovered until it is too late. Don't expect religion to go away anytime soon, no matter how devoid of facts it is.

So we should expect that denying reality will be a big part of human nature forever. The costs will mount, but they will so often be disconnected from the time or people involved that the causes can be plausibly denied.

In I.T. we will just have to concentrate on minimizing the damage and doing the best we can. Maybe in real life, too.

The Shoelace Problem

Since I'm starting a blog I might as well write about something that I've noticed when getting started on something new.

It's going to be a great day today. You have great things planned. You're going to fly the Space Shuttle to the top of Mount Everest to collect your Lottery prize. All you have to do is start by walking out the door.

Damn. Your shoelaces won't tie. Strange, try again. Nope, some module threw a ShoelaceTieException. Never seen that before. Hmm... they worked fine yesterday. It's the same shoes, and the same feet. And now you're standing here feeling stupid because you can't even get out the door. Everybody knows you can't walk through a door without your shoelaces tied.

The "Shoelace Problem" hits you right at the beginning, is usually unexpected, seems trivial and yet is a total show stopper.

Lately I've seen a lot of Shoelace Problems. The quick little project where the software install fails. The EJB compiler tool that throws a NullPointerException for your trivial Hello World EJB. The DataSource JNDI name you can't seem to look up. The App Server that won't start.

It's like the phrase "fell at the first hurdle", except that in I.T. there are so many different ways to fall. Of course there are also the non-I.T. variants. You may be familiar with the following phrases:

• She's on holiday
• We don't have a computer for you
• The requirements aren't ready
• The Business Case isn't signed off

Still, I should be grateful that during a recent power cut (at 8:30 AM) I had arrived early enough not to be trapped in the elevator. Now that's a shoelace problem.