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. 

Scrimmage with Bashir

Usually, it's a sign of maturity when a software company hiring a development manager, where no manager has trod before. A sign that the business is expanding, that the team is attempting to learn from its mistakes. That was what I thought when they brought Bashir aboard at the firm where I was working as a low-intermediate developer.

Bash was an old friend of the senior elements of the team. He'd been through the same Phd program as they had and he was always the rockstar of the group. Bash could have been a stand up comedian; he could have had his own TV show; if he hadn't been married he could have had any girl he wanted. It was entirely likely that Bash would go out on patrol at nights, wearing his underpants on the outside, to fight crime.

After weeks of build up, Bashir turned out to be a personable, articulate, goateed, youngish dude. Seemed like a nice guy.  I had never worked under a proper dev manager before, so it took me a little bit longer to realize that I was dealing with a full-blooded corporate psychopath.

As soon as he took over the development group, Bashir started to address all of the obvious failings of the group. He staffed up, adding a QA department and another engineer to handle configuration management. then he started instituting procedures and processes. All of this was exactly what we needed, and I was very pleased that, finally, we were starting to act like a real software business. On paper, this was exactly what we needed.

Bashir, of course, was keen to hire either a/ people he knew from elsewhere and who he assumed would be devoutly loyal to him for finding them jobs, regardless of competence, or b/ whoever came cheapest. The new hires were all of them nice people, but quality varied.

Bashir had set up his team and arranged us all behind the line of scrimmage.... but it wasn't until the first kickoff that I realized he had us facing the wrong way.

Bashir called a meeting to discuss new procedures and processes. At least, that was what the invite said. He started by describing the software development lifecycle--waterfall model, of course, familiar to every computer science graduate of the last 25 years. But alarm bells started ringing when he got down into the day-to-day expectations he had of the development team.

Firstly, he wanted us to all keep our working copies of the source code on a network drive. That's right--fifteen developers would all be sharing a single drive, over the network, to work on a codebase of about 1.5 million lines. This was to prevent the danger of data loss, because apparently it was too difficult to back up individual machines on the network.

The next policy he had was that we needed the QA manager's written approval before we were allowed to check out a code module from source control.  Neelam, the holder of that new position, was a lovely woman who had graduated from a Comp. Sci program without any ability to code whatsoever. She was, however, pretty good at filling out forms.

In order to work on existing code, we had to have written approval from somebody non-technical.

I was used to working in an environment where your work was heavily scrutinized. Code reviews were lengthy and painful procedures when you finished any task, so the senior team members could ensure that your work met coding standards and followed the design. But here, under Bashir, somebody who couldn't read code had to give you permission to start work. There was no procedure for the end of a task--you checked your work in willy nilly and forgot about it.

I suggested (since this was supposed to be a discussion) that we were managing the wrong end of the process. No harm can come to the codebase before a programmer starts to work on it. "Checkouts are harmless," I said. "But we do need to manage checkins."

Eventually, Raj, the most senior developer, asked "Why?"

I was dumbfounded. "Because... that's the point where new code gets added to the project and it effects everyone else?"
"Well, obviously," said Raj, in the tones with which a father might address a child who is asking why the sky is up; affectionate and patronizing.
I tried another angle. "Well, how about, two programmers both check in the same file, and their changes are incompatible--or perhaps even in the same area of the code?"  I was pretty sure Raj would have to concede that merge conflicts were a sticky one.
"That' never happened to me int he ten years I've worked here."
"Uh, it happens to me at least one a week."
Raj didn't reply, he just looked around the room and shrugged, as if to say "Kids. They get up to the funniest things."

Bashir smiled at me and said he would take the matter under advisement. He called an end to the meeting and I went back to my office.

In the meantime, Neelam went crying to Bash--"Jared's after my job." Bashir, in turn, told her not to worry: her job (which I guess was pretty much confined to filling out requests, because, as QA manager, testing was beneath her) was safe. Then took out my personnel file and added a note confirming my status as office troublemaker.

Alone in my own office, I made space in a drawer to keep a pile of checkout forms.