> I once had a 20 line, ugly shell script that I wrote turned over to the software engineering department for "official maintenance" and to bring it up to "professional standards". In three months they re-wrote the 20 line shell script into a 200 line Perl script, with everything that actually did something being a system() call that invoked the shell commands that were in my initial script (long ; joined lines remaining intact). But this was now a "professional" program, it had lots of comments (none of which explained what any of the calls were doing, or why), every function was less than one screen, etc. It's the best example I've ever seen of how "coding standards" can make a program hard to deal with.
That is certainly dailywtf worthy, but its also a sign that you screwed up by not following coding standards from the outset.
You fixed a problem (yeah for you) and your boss was happy. He gets to say to his peers in other departments "I've got this hot-shot programming magician who can solve all my problems, and he's all mine NAH-NAH-NAH-NAH." So your boss gives you something else and asks you to hand the old script over to "software engineering."
Software engineering looks at it and pukes. 20 lines of undocumented shell. WTF are they supposed to do with that? They complain to their boss who knows that your boss loves you and will never let you go... so they just get ignored. Some poor smuck is now sitting in "software engineering" with 20lines of shell that do god knows what, but he has to bring it up to "standards" which means perl. He wife is pregnant and his home mortgage is eating 50% of his salary, so he can't risk his job trying to bring the sh*t you dropped on his lap up to standards, so he does the next best thing. He just wraps the whole thing in perl system calls. It does exactly the same thing as yours does and he doesn't have to worry that by replacing your sed with a perl builtin that he might introduce a bug through some esoteric incompatibility between perl and sed handling of unicode strings. If anything goes wrong he can demonstrate that the output is the same as your output so its the same program you gave them.
So the real WTF is why you gave submitted 20 lines of undocumented shell script to systems engineering team for long term maintenance when you knew it wouldn't meet their standards in the first place. It was quick and easy for you yes, but completely opaque to those who were actually in charge of managing it.