I think this story is obviously fake. Any sane VP would realize that it's completely ridiculous to allow a single 'virtuoso' to write a private language that's deployed over the entire system. HOW the heck is a system that takes 2 days to deploy acceptable? And what about the Bus Factor?
Yes. Any time you see someone referred to as a "genius" or "super genius" in a workplace, it's a big red flag that they might be smart, but are generally too smart for their own good. I can see where something like this might be cooked up, but anyone with any real brains/experience would realize it's an awful idea and not do it. The fact this guy did it, and then basically can justify his shit ideas with "'I'll quit and nobody else knows how this works" is the real WTF, but sadly too common. All it takes is one guy whose a good bullshitter and clueless management who don't know or care, or competent management that just doesn't have the time to really look at the ideas, and then you have a situation like this where the clueless company stakes its life on an idiot, and anyone with good ideas that don't involve it gets run out by the psychopath.
Yep, been there. The "Super genius" at one certain place, he wrote abut six times more code than necessary, making any bug almost impossible to find. Once I tried tracking an error back from the error-logging function. I gave up EIGHTEEN levels back, where it jumped through an interface. Never did find the root cause.
In many WTFs it's possible to see how the code base gradually slipped into a poor state, but here it's baffling that anybody - competent or not, sane or not - at some point decided on this design. I'm not surprised that it's a "virtuoso" that came up with it - no mere newbie could ever come up with something this unusual.
There's an insurance company barely 10 miles away from me that has a similarly stupid system. A duhveloper there cobbled together a page versioning system for their frontend. I don't remember what they called it but the icon was abstract art; I think it was supposed to be an arrow pointing out of a box. Every time you hit a "page," it checked dates or something to figure out what version it would pull down. But that's not even the real WTF. This versioning system required its own IDE with a form builder and source control (you still had to use VS for the code behind though). And it used Reflection to link up pseudo-WebForms code based on how the attributes were formatted so it alternated between crashing without explanation and just not triggering events. Radio lists were the worst because they didn't even follow the Web-postback-every-time-somebody-so-much-as-blinks-Forms pattern of hijacking the value attribute with a click handler name so there was no way to actually get a value back from the client and you were reduced to piles of if/elseif statements if it didn't choke somewhere in translation.
Oh, and the best part of that system was that it sat on top of some kind of VBscript "service" architecture. So even if you got through the hell of the interface, it passed through a minimum of six untraceable "services" that could drop it at any time without explanation. And it frequently did, because there was no data type validation anywhere, so they would blindly convert "Deleware" (yeah, I know) to an integer and wind up with an error dialog on the server that nobody could see to click away. That instance would hang and all traffic would fall onto the backup instance until the user backed up and tried a second time and hung that one too. At that point, nobody across seven or eight partner companies could file claims or underwrite policies or whatever that "service" sat in the middle of. It would've been hilarious if I didn't spend three days a week banging my head on the desk debugging this garbage.
In the 1980's I worked for a networking company that was transitioning from processors that average a half meg to ones as "big" as 64 meg. Seems funny now. But our primary debugging tool was reading printed dumps. A printed 64 meg dump could fill a cubicle. The first time we had a problem four analysts took a week (each worked about 60 hours) to find and fix one problem. The bosses formed a special group to build an automated tool to help. Our processor was a 16 meg NCR tower with 200 megs of storage - we could process just 1 full sized dump at a time. Considering the limitations, you probably want your code to be as fast as possible. Unfortunately, they put the genius in charge. He had fallen in love with Smalltalk and wanted to write the application as object oriented. Only, without an object oriented language. He decided to implement the system as a series of filters: x=get_this_contol_block NEXT_CONTROL_BLOCK | get_that_contol_block NEXT_CONTROL_BLOCK... First, lot of typing. Second, after just a few pipes the box would start to thrash. And third, all the analysts were only trained in assembly and couldn't figure out the obscure OO dialect he created. In all our meetings I tried to steer us away from this approach (I wanted to add commands to bash to do the analysis with simple scripts). I never voiced my reservations outside my group. But when it failed to be accepted, guess who became the scapegoat. I was about to be demoted and humiliated because "I wasn't a cheerleader". Instead, I jumped to a different group with a sane director who had been after me for a year but had previously been blocked.
That company, BTW, extinct. The last machine, stuck in a college lab somewhere, shut down in 1999.
Humm... I remember when I worked as software vendor to banks' online trading systems, trivial changes can take days to deploy, thanks to the massively interlocked systems. And UAT to upgrades can take years to complete.
Maybe there's no difference in the eyes of VP for the delay caused by an interlocked system's update or other trivial updates.
My friend, once I had worked on software company and one of its products took one week to just add a button on screen due the high coupling among screen components, business layer and database. The company end up broke.