That's a pretty dim view. Sometimes systems are too complicated, or have swaths of dead code that you spend hours figuring out only to find out they're never referenced anymore.
I'm currently working on a project which was written somewhat poorly with little technical oversight, the result being a minefield of code which is slightly brittle and full of dead codepaths. The old system (which works, is complicated and creaky, and I spent some days figuring out out things worked) needs rewritten and if we weren't pressed for time I'd rewrite it in a heartbeat.
Given a goal, an API spec, expected behavior one can rewrite a system which one doesn't truly understand and still do it better.
Certainly, something built by one person is rarely the best. That being said, what's wrong with occasionally taking out the trash?
Personal confession, I was stuck with the NFS lock manager in SunOS 4.0. I inherited it after it had been written by a mathematician who understood the theory of how it would work, but unfortunately could not write code, and it was then given to a person who could make anything work, even if they didn't understand how it was supposed to work.
The result was exactly as you describe, functions which had clear logical errors but they were never called so it didn't matter, data structures where a third of the members were never populated. It took me a couple of months of back and forth before I felt I could even begin to attack it. And after implementing the kernel half and starting in on the daemon proper, Sun discovered 'divisions' and I found myself documenting like crazy so that I could 'hand off' something that wasn't a 'networking' problem.
I particularly liked the n-level deadlock detection algorithm, that was the experience that taught me that a data structure can represent a large set of potential computations all at once.
In my experience, when you have a system that works, is creaky, and you have to spend days to understand how thing work, there is at best a significant gap between actual and specified behavior. Most of the times, there is actually no spec at all, it is mostly implementation defined. And you rarely have the same team as the one who did the previous team (people left, have to work on other projects, etc...).
That's one of the fundamental issue with complete rewritea: the systems you could most easily rewrite are often the one you don't need to.
I'm currently working on a project which was written somewhat poorly with little technical oversight, the result being a minefield of code which is slightly brittle and full of dead codepaths. The old system (which works, is complicated and creaky, and I spent some days figuring out out things worked) needs rewritten and if we weren't pressed for time I'd rewrite it in a heartbeat.
Given a goal, an API spec, expected behavior one can rewrite a system which one doesn't truly understand and still do it better.
Certainly, something built by one person is rarely the best. That being said, what's wrong with occasionally taking out the trash?