Legacy

First draft of Legacy is done.  In this episode Mark finds out that perception is everything.

Here is a snippet I posted to Reddit (Click here to up-vote.)

....

GASMAN was originally written by a fellow named Dmitri Isayev.  I never met Dmitri but I had heard about him through our client Bob in Gas Marketing.  Bob, the group lead, spoke glowingly about Dmitri and according to him Dmitri was the smartest IT guy around.  He had a PhD in mathematics and was brilliant.  He understood every requirement Bob gave him in the three years Dmitri wrote GASMAN, including some of the complex calculations (that I never got to see how complex they actually were.) I had the feeling Dmitri could walk on water. Dmitri had left Banana almost a year before I got there to go work in IT finance in Toronto.  Alan inherited Dmitri’s legacy and everything was going well, at least Alan never heard from Bob or any of the other traders.

 It waited for my shift before Bob called with an unusual dilemma.  Dmitri had implemented a brilliant, granular security on the transactions.  Only certain individuals or roles were allowed to certain data within a transaction and Dmitri had implemented this mathematically inspired security infrastructure.  Bob complained that one of the junior traders was seeing information he shouldn’t of so I set about trying to figure out why.  I anticipated my call to Alan would be unproductive.  It worked per specification according to him. So I jumped into the code with my handy-dandy debugger tool.  I found the security module.  I put in my break points and watch variables.  To my surprise, the program whizzed on by without triggering them.

My first thought was that I hadn’t done something right in configuring my debugger so I fiddled a bit with no change. Then I looked closer look at the code through my integrated development environment.  I tried to discover where the security code was called.  I found it was never called from anywhere.  I did a deeper dive only to discover that a lot of it was never fully implemented, and what was implemented would never work.   There were recursive calls and other strange instruments. For all intents and purposes there was no data security in GASMAN.

I tried to find out if GASMAN was ever code reviewed.  No one knew, and there were no documents to artifact that anyone aside from Dmitri looked at it.  It didn’t even seem to have user acceptance testing or client sign off.  When I asked Anne what I should do, she told me to talk to Bob.  I scheduled a meeting.

“Hey Bob, I wanted to talk to you about the security issue in GASMAN,” I said.  Bob was a portly fellow and outwardly quite jovial.

“You found it?” he said somewhat excited.

“Well, yes.  The security portion of GASMAN was never completed,” I replied.

“Sure it was.  I saw it working,” Bob replied. “Dmitri showed me the test cases.”

I wasn’t sure how to respond.  Maybe it had worked at some point but Dmitri forgot to check in the code under version control?  “I went through the code Bob and traced it.  There really is no security code.”

“That’s simply not possible,” Bob said with apparent frustration. “You must be wrong.”

“Trust me Bob,” I said, “I spent a lot of time going over it and it looks like it was never completed.  It’s not called by any other part of GASMAN.”

“Dmitri wouldn’t do that,” Bob stated flatly. “I saw it working.  I want someone else to look at it.”

I was stunned into silence for a moment but then I just blurted out, “Listen Bob, believe what you like, but why don’t you try it yourself?  Any user can see anything, and it’s not a bug.  If Dmitri did have it working, he didn’t leave the code behind, and it’s not what is running in production.”

“I will,” Bob said gnashing his teeth.  Our meeting was over.

The next day I arrived to see a meeting request in my inbox from Anne concerning GASMAN.  When I met her in her office she told me that Bob had complained about my unprofessional demeanor: Why don’t I like Dmitri? Why would I lie about Dmitri? I recalled and recited my meeting with Bob in great detail.

“So you see - one way or another - it doesn’t work, and it looks like it never worked.  It’s dead code,” I said. “I don’t know how else I could have explained it to Bob.”

“I know, I trust you,” Anne said.  “The client really holds Dmitri in high regard.  To make things easier, and reduce the heat a little, I’m going to assign this to Kenneth.”

You are going to pour gasoline on a freaking fire? I thought.  The guy has no people skills whatsoever. “That’s fine with me,” I said.  I didn’t know I could feel so relieved and pissed off at the same time.

....

Back-Story
The GASMAN story line happened to me when I was working for a financial systems company.  I was hired to come in and finish a complex role based data security feature that was left in an unknown state.  The developer before me had spent two years on the problem, and I was told to get it working, but not change it substantially.  Sure enough as I started to analyze the code I found recursive sections and major chunks that would not/could not work.  It all became moot when I started to trace back to who actually called the code - only to discover it was never called anywhere.  There were tests that didn't test the functionality, but management believed because tests existed, it must actually work.

I blended this into another experience where I had to maintain an application by a developer who was very popular with the client.  The client was resentful that the developer was off-boarded during a reorg and didn't want to give me a chance to provide service.  This problem will be explored in a future story - where you build personal relationships with clients that get obliterated by lack of organizational change management and impact assessment.

The SNUPEA story line happened to me several times in my career.  Rewriting a large chunk of code or an entire, working application - just to understand it - when you could just ask the right people the right questions or read the documentation (when it exists of course) - is just mind boggling.  I had one fellow rebuild something in six months that I built in one - not that I'm saying I did it quicker - but it is a total waste of time and effort to rebuild working, tested code or fix things that aren't broken.  These mistakes usually get caught if you have periodic peer review or effective project/program management.  This theme will reappear in later stories... around the "I just replaced a whole thwack of working code that I didn't understand why it was there with some OpenSource libraries that were totally busted and subsequently derailed the project 6 weeks."