In his absence, I found that the software he had designed, built, and deserted was not one system, but three. They were separate in coding, but united in appearance to the user, and they didn't share storage for keeping the users' data in memory.
Whenever a user's tasks required switch between systems, the user saw a screen with a message along the lines of "Thanks for your input, please click this button to continue." Behind the scenes, the sending system created a form, invisible to the user, and transmitted it to the user's browser. Upon clicking that button, the user would submit the hidden data to the receiving system. The trouble was that the redesigned templates asked for those intermediate screens to be removed. Thus, I had to build tunnels into the systems, so they could talk to each other.
Rerouting this information through the database wasn't possible: There wasn't just one database connected via a wrapper, but two databases intertwined among three levels of software. And normally the wrapper wouldn't know the structure of the database to make it easily exchangeable, but these three did. Any addition to the databases' structure required changes to all the wrappers.
I dealt with it by adding a fourth system and dedicating it as the one all systems turned to for session data -- but all activity ground to a halt. In implementing the fourth system, I had corrected the output of one class (software component) that was erroneous.
I soon learned that the erroneous output was going through other classes that fixed the output -- actually, several classes, depending on the origins of the class first mentioned. Each fixed the erroneous output in a different way, based on its intended usage.
I tried to track down where this class was called from and who expected what of it. But it was impossible to tell because there were so many places. Instead of fixing it, I made a copy, corrected the copy, and used the correction in my design -- never again touching the original.
From bad to worse
I hadn't given my project manager any updates (another mistake), and he hadn't asked for any. After three days I dug myself free and informed him I might need another three days.
He was not pleased. Based on my estimate, he'd put in a contract for six days and planned on the project taking a fraction of that stretch. He'd also notified the customer that we'd complete the project faster than expected and calculated a bonus based on the free time for which we'd bill the customer. Already informed, senior staff were expecting this windfall.
He ordered that I finish the project, then dismissed me. I wasn't given an opportunity to explain myself -- or a second chance. A week later, I found out through the grapevine (nobody talked to me in person) that I wouldn't get a follow-up assignment. I was to leave as soon as I finished.
The temp agency must have heard the same. Before, it'd been quick to communicate and eagerly promised follow-up assignments. Now it went silent except for a registered letter severing future contract between us.
At the end of my last day, my soon-to-be ex-colleagues readied themselves for a holiday party with the customer. That software was live on the customer's site for some years after, unchanged, from what I could tell. I wonder if the customer ever learned or even cared what lurked under the hood.
I moved on to a much better job with a better sense of how to manage expectations -- and an eye for red flags.
Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to firstname.lastname@example.org. If we publish it, we'll send you a $50 American Express gift cheque.
This story, "Congrats on the new job! Please disregard all the red flags," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.