Yesterday, we asked you for the most creative, dream job title you could come up with. We've had some great responses, but we'll give you a couple more days to think of a few more. And we thought this little story might egg you on. The intern at RhetoricalQuestion.com has jumped into the "bosses from hell" fray. It's really a geek-in-training nightmare, and we think you'll enjoy it. Thanks and good luck!
"I have worked at some downright shoddy companies before coming to
RhetoricalQuestion.com. One of them was a major bank. Somehow, the moment
I saw the words "horror story," this project came to mind.
Way back when I was a carefree co-op student with a relatively
non-technical sounding resume, I was tossed into software testing. (HR
figured that testing an application written in Java -- the code for which I
never saw -- would teach me to program in Java.) The application was a
little retirement calculator. You know, type in how much money you have,
how much you intend to save, and it tells you how much in debt you're going
to be when you die.
This was a delta project at the bank, which means that on a priority scale
of 1-4 (where 1 is the highest priority), it was a 4. Which also means
that there was 4 times as much stupidity involved in the management.
Using a visual programming tool -- which they had at the bank -- this
entire thing could be written by 1 person in no more than 2 days.
Moreover, changes to the requirements could be incorporated quickly, and
the testing group would only need to test actual calculations. But of
course, this approach would make sense, so of course they couldn't do it
that way.
On top of this, the team was unbalanced. The internal client was a 3
person team (or maybe even more -- we never dealt with anyone else,
though.) Then there was an additional business person on our side. And 1
development lead (who didn't actually develop anything for this project --
she just "led" the development effort.) Plus 2 networking people -- who
essentially installed the program on into the testing environment. And 1
IBM consultant. And 3 testers, including the test lead and yours truly.
And the project manager. And god knows how many people on the French
Translation Team in Montreal. (The French translation requirement got
dumped halfway through the project.) Finally, there was 1 (count him again,
1) actual developer coding the program. (He got a little swamped by the
end of the project, and they brought in 3 more people to help him out.)
Keep in mind. This is a calculator. Put in a few values, get a result. Done.
The entire project: five months. Month 1 was all the requirements. Most of
these requirements had to be fixed due to a lack of foresight. For
example, you could enter a planned retirement year that was BEFORE the
current year without generating any kind of an error.
The client/business team never asked such questions. The testing team did,
but that was after the thing was mostly developed.
My favourite problem was the lack of research they put into the deployment.
You see, they were building this massive web-based application at the same
time. The sole purpose of this application was to be "leading edge" -- at
present, they've been developing this application for 3 years. The Java
language has since gone through 3 major versions.
This little calculator was a Java application. They wanted to launch it
from a web browser. Unfortunately, this is impossible -- only applets can
be launched from a web browser. There is no workaround, other than start
from scratch or dump the requirement. They dumped the requirement, which
caused a whole slew of other requirement problems.
Had they spent 10 minutes on the internet researching this, they would know
better. Unfortunately, at the time (late 1997) the bank had only one
Internet connection in the building for all 1000+ people there.
Yes. Exactly one. There was a 28.8 modem in the technical library. That
was slowly changing during that time, but I don't think it would have
mattered. They just figured that Java = Internet. End of story.
Anyway, the final four months of the project was testing and development.
For three months of this, there was only 1 developer. And there were 3
testers. So let's just say that the number of bugs far exceeded the poor
guy's ability to fix them. He was a good developer, but he was just a tad
overwhelmed.
I hung on to a report for the list of bugs encountered during this project.
There were 313 of them -- I personally found 146 bugs. This does not
include the bugs that we were told merge into unrelated bugs in order to
keep the numbers down. Only 201 of them were actual code changes. The
remainder were Phase 2 fixes (i.e., we ran out of time), requirement
changes, "As Per Design", or duplicates. Many of those duplicates were
marked as such to keep the numbers down.
My favourite incident was the time that the Vice-President for the
department told us that there wouldn't be so many problems with the
calculator if the testing team didn't find so many bugs.
Then there was the decision to make code changes during the testing cycle,
thus corrupting all of our testing results. Reason: the developer needed
the extra time to make all the fixes. He couldn't afford to do a code
freeze. (Poor guy -- by then end of the project, every bug we showed him
made him laugh in that "I just cracked. Please kill me" sort of way. But
he used to be a tester, so he understood.)
And then there was the original developer, who agreed to do all the initial
set up, but didn't want to fully develop the project because he didn't want
to get into the nit-picky details of (for example) making the printouts
look pretty. The pulled him in to make the printouts look pretty.
Oh, and the clients, who were supposed to provide us with test cases for
the calculations and the graph output. We didn't get the test cases until
3 months into the project. When they finally arrived, there was exactly 1
test case for graphing.
I'm pretty good with math, and so I got to take responsibility for the
calculation test cases. I discovered that the test cases had errors in
them. It took days to get the test cases fixed, since the co-op student
for the client (who made up the cases) claimed that it wasn't his job to do
it because that's not what he was hired for, and the business person on our
side said that it wasn't her job to do it, since the client agreed to
provide the calculation test cases.
The client co-op student said that it was the testing team's
responsibility. It ended up that I went through everything, said which
cases I though were wrong and what the correct values should be, and the
other co-op student would say "Yes, you are right" and give the official
sign-off on them.
I could not get out of that place fast enough. I spent the final month of
that term redesigning my resume.
Moral of the story: never work for a bank."
