Sometimes, one of the most relevant skills that a developer needs to have, when working in the corporate environment, is to know how and when to bend the rules.

A major high-street bank once offered me a completely impossible design brief. As I was being paid by the hour I took it gladly. The brief was to design, and help to build, a telephone-based retail banking system for a new call centre. This was to take over many of the functions traditionally carried out at branch level. By the time I’d arrived on the scene, they had already decided that it was to be a client-server application built in Visual Basic for the client side with SQL Server at the back end. They didn’t know quite what they wanted but they knew what it was to be built in. As if the wedding-guests had decided on the venue, and Hymns, before the bride and groom had met.

When word spread around the enterprise that the project was underway, the Retail Bankers suffered a strange amnesia. When asked by a systems analyst what their retail banking processes consisted of, they professed a strange ignorance. They understood that replacing the traditional functions of the bank with a call-centre would not be good for their careers. High-Street banks would be ‘Rationalised’. They wanted no part in it.

Fairly quickly, I realised that I was the technical architect for a doomed project. The scope was undefined, the system analysis hadn’t been done, and the interfaces with the existing banking systems hadn’t been started. It was little comfort that at least they’d decided on Visual Basic. What made it worse was that the corporate regulations for IT systems insisted on a six-week test cycle for each software release. The Call Centre was to go live in nine months, and the staff had to be already trained for the new system. The trainers needed to have the final version of the software in place so they could prepare their training materials before training could start.

The solution to this intractable problem occurred to me fairly rapidly after trawling through the corporate computer manual. If we could identify all the component banking tasks, we could represent the processes in a high-level (4GL) retail banking ‘workflow’ language. We would create our own scripting language, which was then executed by an interpreter written in Visual Basic. I checked with the high-priests of the IT Department, who confirmed that the actual scripts would not need separate test cycles. It was enough to test the script interpreter. In effect, testing could then be done in parallel with the development of the scripts.

I soon had a development system in place. We checked it out with simple scenarios such as a customer calling to check how much was in her account. I handed it over to the development team who then refused to have anything to do with it.

Normally, with developers, one can quickly find out what is irking them. In this case, there was diffuse moodiness and petulance. They hated the code I’d developed, and hated the project, and hated the solution I’d thought up for survival; but they couldn’t articulate an alternative.

After a few days of hell, the real reason popped out. They felt that the work wouldn’t look good on their CVs. They were VB programmers who wanted experience in all the new buzzword-technologies that Microsoft’s marketing department could come up with. A programmer could wear these TLAs (Three-letter Acronyms) on his CV to enhance his status, like a tribal elder with his shiny beads. Worse, they felt that developing workflow systems in a unique scripting language wasn’t VB programming, their ‘raison D’ être’. All the clever stuff was closely bound to the workflow interpreter that executed the scripts. Everyone was fearful of going near the interpreter because it smacked of Computer Science: anathema to the jobbing programmer.

Once I realised the problem, I felt enormously sympathetic. Were the IT industry a rational place, it would seem a silly anxiety to have, but one must live by the bizarre rules of a nutty game.

We reached a compromise: We would create a module, a part of the project that would adopt all the latest hot technologies that would look good in the CV. We would ensure that it didn’t matter whether it worked or not. We’d all take it in turns to work on it in return for which we’d do a stretch sweating away on the hard work of creating the scripts for the banking processes, and developing the interpreter, and underlying database. This meant that we were all able to claim real practical experience in the hot technologies, but do some real work too. I took great pleasure in designing a dazzling module for printing out the correspondence; confirmation letters and so on that were generated by the banking processes. It was TLA heaven. As a backstop, We also created a much simpler module that duplicated the functionality in a less elegant way.

The ‘playpen’ idea worked perfectly. The senior managers were ecstatic. They could boast that the project was using all the latest Microsoft technologies. The programmers could brush up their CVs until they glowed. We could progress on with creating the application

The ruse of using scripts worked perfectly. The VB script-processor scraped through testing, almost on schedule. Even with the project live, with a vast call-centre humming with people, we were able to modify the scripts ‘on the fly’, without a frown from the bank’s IT department. This was all very fortuitous, since, at the last minute, the Retail Bankers realised that passive resistance would not stop the project, and their amnesia evaporated. They were falling over themselves to help with scripting all the banking processes, and being identified as one of the key participants in the project. The great enterprise got its call centre on time by a simple study of the corporate IT rules, to find the loopholes.