"The boss took one look at the speed test, and shook his head. ‘We can't ship that,’ he said, ‘it's far too embarrassing. We'll have to deliberately slow it back down again, and ship lots of incremental speed upgrades.’"
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.
It's too bad the relevant technical details of the story were overwhelmed by what felt a lot like arrogance and contempt for anyone without extensive experience with parsers.
I think it was more along the lines of "contempt for anyone who, when asked to write code to do something difficult that they're unfamiliar with, chooses to write very, very bad code instead of learning the bare minimum needed to do a passable if amateurish job". For what it's worth, a day or two reading a decent textbook would provide sufficient "extensive experience with parsers" to avoid most of the horrible mistakes described.
Intolerance for egregious unprofessionalism and incompetence is not exactly something our field suffers due to an excess of.
You don't need "extensive experience with parsers" to do what the OP is describing. Lex and yacc (and their moral equivalents in other languages) were written precisely so that a programmer of ordinary skill could write a parser and feel reasonably confident that it would behave properly.
I've done this kind of thing more than once, even back when I was fairly junior as a programmer.
To be fair, a parser shouldn't by written by "anyone without extensive experience with parsers," and it was unethical for his company to sell such a thing.
I know that until, say, 3 years ago, I wouldn't know a thing about parsers, and if they boss wanted a scripting language, I would have parsed the whole thing by hand in C. It would have been a total nightmare to maintain (and develop) and would have been awful.
Now I know about lex and yacc and I know what a parser really is. If everybody at the company was a bunch of random engineers or something with no experience with language design or parsers, its totally understandable that something like that could happen.
I'm strangely reminded of SQL syntax (emphasis mine):
"The language contained an operator ITEM n OF s, which would return the nth word of the string s. (Yes, that was a basic operator in the expression language; a function call syntax or a separate standard library would certainly have been well beyond the programmer's mental horizon.) But you could also alter the implicit use of whitespace as the ‘word’ separator, by writing ITEM n OF s SEPARATED BY d; this would allow you to, say, fetch the third field of a colon-delimited line. So far, nothing too out of the ordinary – except that one now naturally wonders which way ITEM a OF ITEM b OF c SEPARATED BY d would bracket, since it's exactly isomorphic to the well-known if–else ambiguity."
Between your lack of comprehension of "factor of 20 speedup" and "20 orders of magnitude", combined with the fact that this seems to be the person who wrote PuTTY, I'm pretty sure he wouldn't want to be working for you anyway.
Also, when did it become wrong to point out people's stupidity when they do something as utterly stupid as (quite clearly) demonstrated in the article?
Classic.