A long time ago in a galaxy far, far away I spent a month to reengineer a billing program. Previously, it needed 24h to issue monthly bills; after the reengineering it finished in under a minute. It was an easy target, the previous guy had that "hacker" style of thinking which resulted in a program being a pile of quick fixes.
"Hacker-style," doesn't mean completely abandoning all planning and thoughtfulness. It means rapid prototyping, sure, and (of course) constant refactoring, not a constant deluge of slapdash quick fixes.
What you inherited was a garden variety mess, possible from any poor practitioner of any school.
That's because it was likely just a pile of quick fixes. At first, most accounting systems are nice and fast, but then one of the guys over in marketing needs this feature added, and one of the managers wants to be able to track his employees in it.
Over time what may have been a relatively quick, agile system has ground to a halt because of all these "Features" tacked on. Does this mean the original style of programming was wrong? Does this mean that every time a new feature or bug was found the entire system should have been reengineered? No. That's what they hired you to fix. It took you a month to recreate the software, with all of the current features built into it. Since the only other real alternative is to keep a developer on hand all the time to re-write the software when needed, the "hack some features on" method seems to be far more cost effective.
But - you had a perfect spec. You had a working program you could use as a reference implementation, and despite rewriting everything, you knew exactly what it needed to do.
The original implementer presumably did not. In reality, you were taking the "hacker" approach, but your iteration was to rewrite everything, because you knew exactly what was wrong with it. The first guy, if he was a true hacker, probably would have abandoned the fixes at some point and done the rewrite as well.
