Of all the reasons 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?"
- Every environment has some customization that is, in itself, relatively trivial, but is sufficiently environment-specific that it is hard to implement in a program meant for other environments. When you contemplate the programming difficult, you calculate the difficulty of adding that customization, not the problem as a whole, forgetting all the difficult problems that the existing system has already solved.
- Small and specific versions of the problem are easy to solve; scaling and customization are the hard parts. You can solve your organization's whole current problem easily and will not discover the lurking traps until later (the timecard programs works great until employees start moving between time zones, the bug tracking system works fine until a million bugs, the trouble ticket system works fine until the second group of people need to use it, the monitoring system deals with the network devices fine but stumbles when you need to manage systems).
- The underlying parts of the problem are relatively tractable, but putting a user interface onto it that isn't disgusting and hard to use for large portions of the user base is difficult. (Do user interface designer design beautiful interfaces for things that then nobody can program the backend to adequately? Probably.) In this case, even if your program works right, the users will think it sucks. See, for instance, every time card system I have ever been forced to suffer through, most of which seemed quite competent at dealing with my more normal time card needs, after I had learned to perform the arcane rituals needed to actually enter the data. Nevertheless, once your program has made me cry, I do not care that it was just a few hundred UI issues, not a fundamental algorithmic flaw.