Bashir's Way

Things didn't go so well once we started to do things Bashir's way. Although his regime was better-organized than the chaos which had preceded it, it quickly became apparent that less was getting done under the new systems than we had seen under the old (in which the owner of the company yelled and screamed and threatened until the work was complete).

There were several reasons for this. Firstly, requiring all developers to keep their working copies of the source code on a single network drive mean that it took more than double the amount of time for us to do anything, just due to disk access.

Secondly, the red tape overhead was huge. In addition to the checkout forms, we had to update a spreadsheet with the work we were doing, we had to track our hours on quickbooks timer, we had to submit an hour-by-hour breakdown every week, and we had to sign in and out of the building every day. Bashir's answer? Add more tape.

Bash and Eric had turned the excel spreadsheet into an access database and then they came and asked me (The database guy) if I would write a front-end for it so that the dev team could use it instead of the excel spreadsheet. "I can, sure," I said, "But it's not going to work on Access."
"Why not, Jared?" asked Bashir, rolling his eyes.
"Access does not support multiple users. If you have fifteen developers on this thing all day it's going to break."
"Fine," said Eric. "I'll get Gavin to do it."
Gavin built it in record time. It took about a week before it blew up, and I heard Eric lamenting to Gavin (whose opposite was directly across the hall from mine) "How were we to know that access didn't support more than one user?"

Bashir's process, as he had explained to us with a great number of drawings and, was the familiar development cycle: Requirements are gathered, features are build, QA tests them, development fixes bugs  until is satisfied, software is released. Wash, rinse and repeat.

Despite everything--and there is a lot more, which I will discuss in future posts--development finished its first release on the scheduled day and the product went to QA for testing. Neelam and her single junior tester (a nineteen-year-old kid named Colin) went to work and a week later--the end of their QA cycle--they came back to Bashir with a list of which defects had failed QA. Bash was furious! The release was supposed to go out the next day, how dare we fail to fix some bugs the first time! How dare QA fail to rubberstamp the release?

I helpfully pointed out that Bashir's chart showed a cycle from QA to development prior to release, but his schedule did not allow for this. A corresponding black mark went into my personnel file. It would be a while yet before Bashir threatened to fire me for the first time.