I also spent some time reviewing a colleague's >10KLOC shell application, during which my most repeated (verbal) review comment was ".. and at what point did you realise that writing this in shell was a really stupid idea?"

I feel your pain. Sounds like he got you to review the code after it was "done". Is that right? If so, it looks like an example of the classic Beware of a guy in a room anti-pattern. He should have been discussing the general approach with the team long before going off to create his shell script monstrosity.

I see this was back in 2008-2009. I trust this sort of dysfunctional teamwork would not occur at Google today, given their seminal gTeams study of 2015/2016 (discussed at Working Solo and in a Team and Psychological Safety).

After being burned by a number of similar incidents, I had a rare success at work, managing to persuade all of R&D to stop writing Unix shell (and Windows BAT) monstrosities, based on the arguments put forward in Unix shell versus Perl.

I think he'd been looking for someone prepared to review it for quite a while. The team was split across Mountain View and Dublin (with Dublin the smaller and very much the junior part), and this was during my initial visit to Mountain View shortly after I joined. I suspect getting me to review it was intended as a kind of hazing of the newbie, but I didn't actually mind it at all since I'm a big fan of code review and considered it comfortably within my competency.

This being SRE most of them had a primary background in system administration with a sideline of programming rather than the other way round as in my case, so writing a big bunch of shell may not have seemed an entirely unnatural choice. Within the context of multi-KLOC shell applications, it was actually pretty well written - I learned quite a bit about shell programming in the process. But of course I can has perl, so I've since forgotten it all again. :)