Yes, definitely. If this was anything like my own experience writing parsers both the wrong way and the right way, the original programmer probably could have saved time by going out and reading a couple of textbook chapters, doing the homework problems, and reading the Bison or ANTLR manuals, and then doing it properly. Implementing a parser without knowing what you're doing is not quick or easy.
Worse than that, it is a frustrating, Sisyphean endeavor, always taking one step forward and two steps back once you get past a certain point. It is not a task I'd wish on anyone. It's a lot like writing a multithreaded program when you don't have a clue; you get a few quick things working and then descend into an endless hell of fixing one bug and causing two others, forever.
But as a programmer, if you know that you have to write a parser, you should take a few minutes to google it before writing the code and see if this isn't already a solved problem. And it is, essentially; there are so many parser libraries out there.
I can even speak from experience on that. In my internship during my first year of university, I found myself wanting to write a little parser to read config files for my program. It would have been something like "double myvalue = 42\nint myotherval = 20" etc. I figured this should be a very common problem, since so many programs use this kind of configuration. Googling it let me find even better, cross-platform config libraries which use the registry on windows or config files on other platforms, and saved me from writing the parser in the first place.
If it did the job, it's already ahead of a lot of code out there. Sure, the code was bad and not thought through.
That's kind of how I code when I don't care and need a quick workaround :-)
It takes special people to write beautiful code 100% of the time.