"it" vs IT
-
A long, long time ago (sometime last year), in an IT shop (not) so far, far away, "it" was conceived by our Support team. "It" was to be the solution to all of the evils that plagued our support personnel. "It" was to be implemented such that "it" would never ever need to be maintained, updated, configured, or in any way supported by IT (no pun intended) folks - who take far too long to do this stuff - ever again.
The Support team decreed that "It" was to be the Mother of all Configuration Tool's. "It" was to provide a single interface to allow support folks to configure not only every single one of our (very different) applications, but all of the new ones that they might someday need for as yet unimagined/undesigned products, all without ever needing to ask the IT folks to update "it" (or the DB) with the new functionality.
Us lowly IT folks (me and my boss) decided that the Support team should design not only the Gui, but the DB schema, synchronization, and the back-and-forth persistent communication required to update live apps with whatever changes they were trying to make with "it". We (IT) set up a special project in the timesheet recording system, so that the Support folks could charge whatever time they spent on designing "it".
Every week, the Support folks would spent many, many hours designing, tweaking, redsigning, and retweaking their oh-so-perfect designs so that they could present them to the IT folks (me and my boss) who would be responsible for developing "it". Every week, we would find one or two more problems with the design (well, we found lots, but only gave the Support team as much as they appeared able to comprehend), and send the Support folks back to the drawing board.
After about a year of this, the Support manager noticed the mounting hours his team had spent on "it" and got together with me and my boss and asked what was taking so long; after all, the whole point of "it" was to eliminate IT because IT always took too long to do stuff. We pointed to the very thick stack of a year's worth of meeting minutes, each detailing fatal flaws in the Support team's design. While we were reading through it all and explaining it to him, you could see the light go on over his head: good software design is hard, and should be left to the experts!
"It" died right then and there, and never again did we ever hear any crap about requesting the time we needed to make the stuff they asked for work properly.
-
@snoofle said:
While we were reading through it all and explaining it to him, you could see the light go on over his head: good software design is hard, and should be left to the experts!
Which is why outsourcing to developers with no formal education and at best a year or two of programming experience for $5/hr. is a huge WTF. One that people keep committing over and over again.</offtopic>
-
-
@RobbieAreBest said:
@snoofle said:
you could see the light go on over his head
Yay! A happy ending.
I learned a long time ago that when someone complains that I'm taking too long to do something, I immediately stop doing it and let them do it. While it *usually* doesn't take more than a day or so for them to beg off, this crew took almost a year to get the message. We were taking bets as to when they would finally "get" that they weren't going to be able to design such a tool, let alone do it right.
