Friday, 22 February 2013

The Perils of Application Development. Part 1: I fire my boss


In the mid-1990’s I was working for a small company that had both a consulting wing and an application development wing. I had begun in the consulting wing when I was purchased from another company along with a contract I had been working on. The contact ended and the new company had trouble finding something of a more or less permanent nature for me, resulting in my working on a patch-work of small projects. Then the departing director of personnel suggested I might fit into the application development group as a C programmer.  Finally something I could get my teeth into after months of writing proposals and doing short-term studies.

Application development had a product that had been many years in the making. What it was was a car-part catalogue generator. What’s the point of that, you might be wondering? Well, the after-sales automotive industry is huge. Car parts wear out and break. Joe’s corner garage needs to be able to identify, order, and have delivered a vital part as quickly as possible while an anxious owner paces the showroom floor. Our application maintained a database of automotive parts that could be accessed by year, make, model, manufacturer, whatever. You need a spring-clip for the front right caliper brake on a 1999 Chevrolet Impala? A quick look in a catalogue index, a few pages turns, and there’s the list of manufacturers of that part, complete with part numbers and pertinent order information. At one time garages specializing in car repairs had banks of such catalogues for reference. Interactive applications were still pretty much in the future at the time. The Internet was still too slow and crude and CDs were expensive and applications for them relatively undeveloped. The result: we prepared catalogues that were intended for print. The fact that we could assemble a catalogue of all steering assembly parts for all GM models from 1950 to 1995 quickly and have the catalogue ready for print within minutes was our market advantage.

For years the team had limped along with one major client, but now a new one was considering coming on board. While they weighed their options and contract details were hammered out, the backend catalogue production code was handed over to me. In the middle of everything sat the database of parts and catalogue templates and definitions. There was a database manager who handled that. The front end was the interface that operators used to both enter the raw data and to define and layout catalogues as required.  After they were done my programs took over, taking their instructions to layout and prepare the catalogue for print, turning their instructions into code that a printer application, like Interleaf, could understand and populating it with the required data.  My result was a coded document ready to be sent to a PostScript-enabled printer. So, while the sales people worked on the contract, I worked my way through the existing code, creating flowcharts to enable quick reference to the logical structure of the code.

The company was, at the time, going through a major restructuring. That’s business-speak for “trouble.” Middle managers were leaving both voluntarily and less so. Verging on bankruptcy, it was dependant on the new catalogue production contract to keep afloat. The company was purchased and split in half; the consulting wing becoming a new company with management promoted from within, the new owner taking a hands-on approach, and the application development wing staying with the now-former owner, Peter, who assumed the role of company president. Where there had been half a dozen layers of management between me and Peter, there were now two layers: a project manager and the senior developer. The senior developer, Charles, had designed and written the backend code that I was now the owner of. Charles’ friend, Steve, had designed the database and was now appointed project manager. There were three junior programmers assigned to the frontend code. Charles’ wife, Sue, was in charge of Quality Assurance. There was also a network manager and a small team of operators whose job it was to input the data and the parameters required for each catalogue.

Just as the contract was approved a new project manager appeared on the scene. I had worked for George in a previous company, though I had had little contact with him. He was a loudly gregarious fellow. The project I worked with him on before had been a disastrous failure, costing millions that were flushed down the toilet despite George’s repeated proclamations of, “Don’t worry; be happy!” To celebrate the winning of the new contract that was going to put the company back in the black, George threw a dinner party at a local restaurant for the entire development team. We arrived to find a bottle of wine on the table before each couple. George ordered pre-dinner drinks, and kept up a steady flow of new bottles of wine as they were emptied; there were after dinner drinks, all with great fanfare. Two days later George disappeared from the company. Apparently spending a couple of thousand dollars on a dinner was not within a near bankrupt company’s operations and policy guidelines.

So, Charles took over as project manager and we got down to work. I enjoyed it and established a good working relationship with the rest of the team, especially with Charles. He was a patient and enthusiastic teacher; however, there was a fair bit of tension between him and Steve who rarely showed up for work. When he did show up, they bickered about the directions to take to address different problems as they arose. When the network manager walked, Charles hired an old friend of his to take over network management. However, she was fired (I never knew why) after about a month. Charles was very bitter about that. Charles then hired someone to work on the development of a CD-based application of the product. Greg, an apparently charming fellow, branched out on his own, hiring two friends to help with the development of the CD. It soon became clear that we were two separate groups; one preparing a paper-oriented product, then other a CD. Greg had no use for Steve, thinking him as a promoter of obsolete methodologies, and spoke disparagingly of Charles and his approach behind his back. For some reason Greg seemed to like me and once confided he felt as if he were a spider weaving an elaborate web within the company.

Though I loved my day-to-day work—solving application problems and seeing my code work evolve—I was uneasy about a couple of things. One was the constant bickering between the two managers in charge of the direction we were going: Charles and Steve. Another was the disconcerting discovery that the database itself was filled with buggy and unpredictable code. Time after time I’d run a new routine that aborted on a fatal error only to discover, on analysis, that the problem was not with my code, but with data that was not in the format that the specifications said it was. Steve didn’t seem to care that it was his haphazard work that was threatening the integrity of the entire project. He had apparently once worked with a well-known database designer—which he would remind us of whenever problems surfaced due to his carelessness. Then there was the constant stream of snide negative remarks about our work flowing from Greg and his group.

A case in point: a few months into the project, the clients wanted a demonstration of our work to date. A half dozen of them arrived from Detroit to be squired around Ottawa and finally introduced to a walk-through of our product. Charles and his wife spent days preparing for the demonstration, carefully marking out a path that they could follow to avoid the known bugs and pitfalls. The clients left satisfied, never knowing that they had just been subjected to a dog and pony show that worked only because of sleight-of-hand and mirrors.

And then Charles, for reasons that were never clear to me, quit and our “paper” group was left leaderless. Greg encouraged me to step up and take over. Peter seemed to have no difficulty with my assumption of a management role and, in fact, praised me in a company meeting for stepping forward when someone was needed to take the helm. I worked with the frontend folks to tailor the product to meet the requirements of the new client while I made the appropriate adjustments in the backend code. We were starting to make progress after a few months of what had been flailing while Charles and Steve fought their battles. The frontend programmer I had most faith in left on maternity leave and then our most junior member left to take an opportunity in the USA. I was left with one, apparently competent but highly neurotic, programmer who offered me a deal: if I gave permission he’d work at home for six weeks and return with a new database loading engine that would eliminate all the errors that Steve had let creep into the works. I agreed.

So now my problem was that whatever adjustments the current database needed I was dependant on Steve—who was never at work. I spoke with Greg about the situation and he suggested the path I subsequently followed: I communicated with Steve through email. I would lay out the requirements for what I needed and ask him when he thought he could deliver. He’d give me a date that, once reached, I would ask him for a progress report. He would then claim he did not know what I was talking about. I’d lay it out again and ask for a new delivery date. And so it went for a few weeks until I had a solid paper trail of his accepting then denying work assignments. I approached the personnel director who opened up Steve’s file. I was surprised to find out that a year before, just before sales had discovered the possibility of a new client, he had been put on a month’s probation for similar reasons. As the new situation developed he had been offered a bribe in the form of project management on the condition that he clean up his act. It had not been working out, which is why George had been hired briefly before his sudden departure. Personnel agreed with me that it was now time for Steve to go. We worked out the approach we would take, asked Steve to come to a meeting in the personnel director’s office, and I fired him. He had gone from being my boss to my escorting him off the premises in less than a year.

Next: Building a new team

No comments:

Post a Comment