Saturday 14 May 2011

Like a Rolling Stone

Gavin Ramsay soon took charge of the department, and he made it clear to us that he wanted one thing, and one thing only from my office. We needed to adapt a part of our functionality to their new project. With that directive, he more or less left us to it.

Bashir consulted Abhiraj and Eric and decided that was not what we were going to do.

I'm not sure what his reasoning was. Raj and Eric had spent their entire careers working on our product and openly admitted that they were afraid of the larger codebase developed by our peers at other sites. Or, really, any code at all that they hadn't spent more than a decade wallowing in. Perhaps Bash thought he could show up the other departments by breaking new ground with our slated-for-the-garbage-heap product, but frankly that seems an unlikely prospect. Perhaps he viewed our group as a hindrance to his progression up the corporate ladder. Whatever the case, he quite deliberately set us to work that was not in accordance with Ramsay's instructions.

Initially, the new projects were pie-in-the-sky crazy. I think they were sold to him as super-high tech, next generation genius projects, but I'm not sure who was kidding who: our software was substandard, out of date, performed like shit and looked like crap and everybody knew it. The first such project was to add the capability to build perfectly vertical surfaces into a Triangular Irregular Network.

This idea left our customers as well as internal people scratching their heads. Aside from missing the point of what a TIN actually was, approximations of those surfaces (where absolutely necessary) were quite within industry standards. TINs do not, by definition, model perfectly vertical surfaces. We decided to do it anyway.

Bash called a meeting for those of us involved in the project. This included me: I had a few minor tasks to do with the database representation of the new data. During this meeting he said that he would present the design document for the new feature and kick this project off 'just like a real one'. I was shocked. A design document? From Bash and Raj? For real?

Bash handed each person a couple of photocopied spreadhseet pages showing the schedule for the project.

"Great, a schedule," I said. "And the design?"
"That is the design," said Bash.
"Uh, this is a task breakdown schedule."
"Right. The design," said Bash, who held PhD in Computer Science who taught Software Engineering at a University in the hours when he wasn't running a branch office of a software giant into the ground.

A few weeks passed and not much happened. I think Raj wasn't able to make the maths work right, or perhaps he just didn't try very hard. My tasks were deferred because, owing to the lack of a design spec, Raj still couldn't identify what new data would need to be kept in the database.

By then, Bash had a new idea. Customers hated the User Interface presented by our software, and with good reason: it was dated and clunky and unintuitive and there were no design standards. At an earlier juncture, I had been assigned a bug that basically instructed me to fix the interface for a particular dialog. I couldn't work out what it was supposed to do, so I went to Raj, who had originally written the dialog and asked for his advice. He couldn't remember either, but instructed me to contact the client he had written it for. I tried; she was not interested in helping me. It did what she needed it to--whatever that was. So I went back to Eric and told him that I couldn't fix it until somebody worked out what it had to do. Eric reassigned the bug to my neighbour, Rog, and before long he checked in a fix and it was marked off the bug list. Seeing that, i went and asked Rog what the dialog was supposed to do. "Hell if I know, Pike," he said. "I changed something random and that was good enough for Eric."

Anyway, our UI was terrible, so one of our analysts went and redesigned a lot of screens to a/ make them useful, and b/ bring them into line with the parent company's design policy. The analyst, of course, had no more UI design training that the guys who had designed the original screens, so this mostly involved removing buttons and and hiding that functionality in bizarrely-ordered right-click context menus. Nonetheless, the show needed to go on and Bash decided that this project was a low-hanging fruit.  He set the whole team onto the project. All ten of us.

We had worked on the new UI  for about six weeks before Bash decided that the project was too risky. We didn't have the QA resources to test the new software, and our single tech writer was already overwhelmed without having to update every screen in the manuals, the tutorials and the help documentation to reflect the new look of the product. All of our work was archived and the codebase was rolled-back. Six weeks of work from a ten man team, rolled back before it was completed. (I didn't dare suggest that we branch the codebase. We were using Sourcesafe for version control, so I guess the matter was moot in any case.

Bash had another new idea for how we could spin our wheels avoiding the work that head office had mandated for us. The most important thing in the business world was the emergence of the Chinese economy, right? So Bash decided that we should bend our every efforts to making the application translatable. Again, in theory, this was a low hanging fruit and it was a way of showing us bringing our software in line with some of the code practices of our new company.

Forgoing the consideration about who was going to do the translation  (Eric? I had a feeling that he was just as inarticulate in his native tongue as in English), fixing the codebase to make this possible was not an easy task. Worse, it was dangerous. Instead of using Unicode, practice at our company was to use MBCS for translatable strings. By far the majority of security and stability problems that occur in any traditional Windows app are due to faulty manipulation of strings. Many experienced programmers struggle with this, and to convert all of these routines to MBCS meant that an already difficult and error-prone aspect of the coding would become substantially more complex and difficult.

Bash decided it was all-hands-on-deck for this task. He uprooted us from our offices and set the whole team up in the big meeting room, (now the 'Lab'). It was our one and only priority.

We worked in the Lab for about a six weeks before the senior team members got annoyed. They were then allowed to return to their offices and their former projects (vertical surfaces in the TIN model, I suppose). The rest of us were transferred to the small meeting room (which was the size of a single office), where we spent another sweltering month on this grindingly cumbersome task. At the end of that month, Bash once again decided that the project was too risky, for exactly the same reasons as he had the UI project. Again, our work was archived and the codebase was rolled back.

We'd now wasted the better part of six months. We had not written one line of code towards the module head office wanted from us their real product, and we'd actually failed to improve our existing software in any way.

During a company-wide video address the CEO told us that there were some big cutbacks coming, including site closures. I was pretty sure I knew what was coming next:

Performance reviews.

No comments:

Post a Comment