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.