Some crashes are OK
I'd been hired to assist with a program that was nearing deployment, and the project lead determined he didn't need my direct involvement on its development. Instead, he reassigned me to help with a performance testing strategy, which I very quickly discovered was not a step this company usually took before rolling out new products.
This particular product was causing numerous system crashes stemming from memory issues and client load, which was around 200. When I put it through a stress test environment in the cloud, it was obvious that this application could not stand up even if it had six legs, due to bad design, poor architecture, and lack of oversight.
I took my findings to the project lead and recommended a total overhaul of the product. He shrugged and said we didn't need to go that far. It would work well enough if we could minimize how often it crashed, and don't worry about the rest.
Though I'd seen enough to not be surprised by this lax attitude, I still was aghast that he didn't seem at all concerned about rolling out an obviously subpar product. Nonetheless, I pinpointed a few areas for improvement. They were made and, voilà, the worst of the crashes stopped. Though still unreliable, the product was released.
Different project, same scenario
I was assigned to another project at this company and relived the same scenario all over again. The timeline, scope, and expectations for the project were impossible. At the outset, the vendor that was helping produce content for this assignment had received technical direction to "make it so" -- then no other word besides our frequent changes in delivery schedule. The project was on track to go over a cliff.
Meawhile, the Three Stooges showed their ignorance and attitude on a daily basis by goofing off, making tech error after error, and not seeming the least bit bothered. In a way, who could blame them? The project lead didn't seem to care what happened.
There was no documentation, no resources, no regular meeting attendance, no direction, no decision-making, no nothing. Time and again, one of the stooges would look around the room and say, "What do you think about doing X with the project -- should we or shouldn't we?" Someone would mumble in reply, and that'd be the extent of the discussion. The "agile" approach was more like a social hour where instead of getting sprint status, it was "Hey, did you see the game last night?" or "Yes, that is done: proceed to test," though at no time was "done" defined.
I guess the silver lining to my time at this company is that I now know to avoid it. I have children in school, and I'm glad their classrooms don't use this company's products -- you'd better believe I checked -- and I feel really bad for those that do. But the company's days are most likely numbered. No business can survive the way they're running theirs.
Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonesense to firstname.lastname@example.org. If we publish it, we'll send you a $50 American Express gift cheque.
This story, "3 stooges and a bozo make a mockery of the IT department," 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.