HowHardCanItBe

Of all the reason that people get sucked into rewriting software, the one that drives me craziest goes like this: "Well, there are a bunch of versions out there, yes, but they all suck. So we decided to write our own. How hard can it be?"

Well, I dunno, it can be hard enough that a bunch of other people tried it, and their versions all suck. It's true, the world is full of mediocre programmers, but take a look at those versions. One commercial version might have been written by 2 bozos in a corner and then shamelessly exploited by a money-grabbing company trying to fill a vacuum. More than one? Longstanding products? Somebody who can do more than grunt was involved at some point. One open source version might have been written by a crackpot and released in a forlorn attempt at self-aggrandizement. More than 5? Some of which are longstanding projects with multiple contributors? Once again, a reasonable amount of brainpower has been unleashed here. If the result sucks, the problem is hard. And unless you have a clever insight they didn't have, your version is also going to suck.

Quite possibly your version is going to suck even if you do have a clever insight, because these problems tend to have two characteristics. One is hidden depths. How hard can it be to write a time-card program? Ask the poor person who wrote one for a company I used to work at, and then got an edict from above that people should be prevented from filling in time sheets for the future. At which point they discovered time zones. In Australia it already is tomorrow, if your server is in California. Worse yet, there was the day I worked a full day in New Zealand, flew back to California, and had a meeting that afternoon. I worked the SAME HOURS twice that day, in two different time zones. And you better bet I wanted them recorded!

Ah, but that's not really a problem, you say. True, the time-zone problem does add significant complexity, but it's not that bad. At this point, experienced programmers are shaking their heads, slowly. This is the road to Hell, and after the first few times you get to recognize the handbasket as you climb in.

Ignoring the fact that we are well into the complexity vortex at this point, let us think about the time zone problem. You just get people to tell you the time zone their hours are in, separately for each hour they work. And at this point, you run headlong into one of the other nasty characteristics of these problems: they're about user interface. Mediocre programming is often invisible. Mediocre user interface is right out there in the user's face. And it's one of the main things that cause people to wander around whining about how much your program sucks. Any time people say all of the existing solutions are horrible, you can bet that there's a user interface issue as well as an underlying issue.

So, if there are a bunch of existing solutions, and they all suck, here is what you know: you are about to experience a sucky solution. You can buy it, you can download it, or you can write it, but when you're done, you're going to be unhappy. Your goal is to be minimally unhappy at minimal expense, and that is almost always going to involve modifying an existing sucky version so as to avoid simply mindlessly repeating other people's mistakes. Make new and better mistakes instead.