Today I’ll cover the story of project number two, “just a little code” to integrate two systems. But first, let’s talk about my motivations.
About the Killer App Series
“The Killer App” is not a work of fiction, or a work of historical fiction. It is not a made-for-TV movie, “inspired by” true events but with the drama cranked up a notch or two; it is history as I recall it.
While it has been a pleasure to get this off my chest, I have no axe to grind. The players have moved on. Enough time and space now separates us that even the “bad guys”, as much as there were bad guys, would probably not recognize themselves in the writing.
Nor is this a case study, all wrapped up in a bow with a key learning takeaway.
The Killer app is … a story.
My story, about a time in my life before I was a writer or consultant, back when Matt was an employee, and, sometimes, felt more than a little trapped by his situation. The story points out that there is more to life than process — that often, it is the sticky blobs of flesh called humans that can make a difference. I didn’t always make the right choices. Back then I was more than a bit scared of conflict. But if a person or two can learn something from the story, and do it with a smile on their face … I hope you’d agree with me to call that success.
Now it’s time for round two.
The Next Killer App
At the end of the killer app, our hero had transferred off the project, to go work on project number two. The transfer was no brilliant duck-and-groove out of the matrix.
The reality was that I failed a code review, so they transferred me to fix the code.
At least, I tried to fail the code review.
You see, the code came to me late in December, between Christmas and New Year’s, with a bow on the end that said it “had to go into production by the end of the year.”
The code itself pushed data from one system into another and provided a total of prescription and medical costs spent per year, which we could use to decide how much to pay for the next claim. It seems simple enough when you explained, but to do it, the company had figured out how our (undocumented) CRM system was storing the data, then write code to notice when the data changed, then have that change flow throughout the system.
And I could not understand what it was doing.
About Code Review
On paper, the code review process was a chance for programmers to learn from each other, to talk about the code standards in place, maybe to recommend changes. The thing was, this application was developed by a contractor with no oversight. He did not know our code standards, and had not done work in our core programming languages before. The design used some new techniques that none of us had seen before; I couldn’t understand what it was doing.
One thing I was sure of was that the software was connecting to a test database, using a test account, and writing files to do test directory that did not exist on the production machine.
I could find show-stopping issues just by looking at the few parts of the code I could understand.
There was no way this was going to work, so I failed the code review. The application could not go to production; it needed a re-write.
The response from management was something I never expected.
A Proportional Response
My manager told me that they were not asking me for approval; that the company was simply asking me to verify that the code review step had occurred. Since I had performed the code review, it was done, therefore the code could be moved to production. “Please list any obvious bugs (like bad directories), and they will be fixed before we put in the change control request.”
If anyone was dodging bullets like Neo, it was management, not me.
Remember, I am an employee. I felt trapped. I didn’t know what to do; I checked the box, the code went into production, it ran quickly for the first few days then slowly bogged down. Of course, the data it spit out was wrong (more about why, perhaps, in a different post). They fired the contractor and over the next few months I slowly rewrote the application.
That was nearly ten years ago.
Some Advice
If I could have given some advice to young Matt, it would have been to take some risk. Send out the email making the bold claim that the software would fail in production, and this would materially impact financial transactions (it did), that moving the code to production would be irresponsible software engineering (it was). Further, that the the company has dozens of programmers; if the code went to production as-is, please do not call me to fix it.
Perhaps just that last part, privately, to my manager.
That might have meant my upward mobility at the company, but I was one of a few ‘sound craftspeople’ who could do the work. They would have kept me around, but not promoted me. Besides, by challenging authority, even in the right way, my upward mobility wasn’t much to speak of anyway.
Instead, I found myself in the awkward position of cleaning up a mess, under incredible pressure to do it quickly, without changing the design (“just fix the bugs”).
I could talk about that, but we’ve got plenty more to cover here, including more on the test competition, and I’d also like to start talking about performance/load testing and profiling.
Let me know what you’d like to hear about in the comments!