| Line: 1 to 1 | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
| Changed: | ||||||||
| < < | Here's mine: | |||||||
| > > | Here are mine.
Dilbert Story 1: The World's Most Expensive Shampoo | |||||||
| GTECH hired a woman to do PR not long before I left. She was a very nice person, and more than 6 feet tall (which isn't relevant to the story at all). As she was hired at about the same time that the whole company was wired for email she sent one of the first all-company broadcast emails. It went something like this (I'm paraphrasing since I didn't have the presence of mind to keep a copy of the email): | ||||||||
| Line: 28 to 30 | ||||||||
| Update: a friend of mine who just started work at MITRE called today to let me know that MITRE has a box by the front door to collect the little bottles of hotel shampoo to give to the needy. Your tax dollars at work. | ||||||||
| Added: | ||||||||
| > > | Story 2: Tinkertoys Aren't Just For Kids Anymore | |||||||
| My second-favorite Dilbert story has to do with the two different times that I was required to attend off-site team-building exercises and ended up building machines out of Tinkertoys instead of generating value for the US GNP. The first time was almost interesting, the second time was pure unadulterated pain. The only saving grace of the whole exercise was when we were assigned a PhD organizational psychologist to help with our group dynamics and we were able to band together as a team and goad him into losing his cool, yelling at us, and threatening to quit. That was fun. | ||||||||
| Added: | ||||||||
| > > | Story 3: The Architect's Hands | |||||||
| I recently had an experience which can only be described as Dilbert-esque. I was working on a contract job with a very self-impressed software "architect". (Note: for the non-technical reader, "software architect" is a very vague and pretentious term but it typically refers to someone who draws pictures but doesn't write software). For some reason he decided that the entire development team needed to stop what they were doing and spend 4 hours watching him draw a document that we had been given weeks before on a whiteboard. The beautiful part was that any questions about how the thing was supposed to work were answered with "I'm not sure, that might change" or "that's a detail that we'll work out during the implementation." We were also told that the drawing was partly obsolete and that it would probably change before we had to code it. In other words the meeting was a complete waste of an afternoon for the entire project. But that's not even the good part. After 3 1/2 hours of this, the "architect" suddenly said "I've got to go wash my hands" and walked out of the room. Again, this is with the entire development staff sitting there, wondering whether the meeting was over, or whether he intended to continue wasting our time. Eventually one of us (ok, me) asked the project manager if we could get back to work but even he was so dumbfounded that he couldn't tell so we all sat there for a couple of minutes waiting for the "architect" to wash his hands and come back into the meeting. | ||||||||
| Changed: | ||||||||
| < < | -- TobyCabot - 19 Oct 2001 - 21 Nov 2002 | |||||||
| > > | Story 4: Build vs. Buy, Why Choose?One common decision in the software business is the "build vs. buy" decision where you decide whether to buy a software product or build something like it. I was recently involved in a project where the decision was "both." As background, there's a kind of software called a "rule engine" that purports to allow non-programmers to write programs by codifying business knowledge as "rules." Anyway, they are typically expensive and balky but feed off the persistent hope that you don't need programmers to write computer programs. Anyway, at the beginning of the project (before writing a single line of code) we were told that we would be using a certain commercial rule engine and had to integrate it into our program. We grumbled about it but ultimately went along even though the rule engine turned into something of a white elephant. Later in the project, though, we quickly had to build another system when a business relationship fell through. This new system seemed to have a need for something like this rule engine, and we had already learned how to integrate it into our code so the obvious choice would seem to be to cut-and-paste the same rule engine into the new product. The Dilbert moment came when we were told that the customer didn't want to pay the additional license fees for the rule engine so we were going to build one from scratch! In summary, we paid for a rule engine that we didn't use, and then when we needed one we built it ourselves. Scott Adams couldn't come up with a more absurd scenario if he tried. | |||||||
| Added: | ||||||||
| > > | -- TobyCabot - 19 Oct 2001 - 18 Apr 2003 | |||||||