Sometimes, one sits back from the screen, pushes back the keyboard, and thinks 'I've done a good job there'. But is a victory over technology always going to cut any ice with the customer?
It often seems to take the participants by surprise when an IT development project slips its dates; sometimes it is the developers who are least expecting it. Why?
I worked, for some time, as a Manager for a large multinational. By chance, two different divisions wanted exactly the same application for working out the manufacturing cost of a new product. One division wanted a state-of-the-art windowing system, built with all the latest TLAs; the other division just wanted "something that worked". Two different cultures became locked in conflict, like giant lizards. In the end, they grunted, and went their separate ways, unable to agree on using the same product, or commissioning the same development.
As a result, two development projects were born, one radical and exciting, and one conservative and dull. I was called in by both divisions as a technical advisor, so ended up keeping a watching brief on both projects. It was a betting man's dream. The two projects had the same aim, but entirely different visions of how to achieve it. As I still bore the campaign scars from my years in managing my own development projects, I was keen to define clear points in the development process where both they and the business divisions could agree that an aim had been fully met with a deliverable, and that we had a common criterion for successful delivery. I broke down each project into bite-sized chunks, or tasks; specific, measurable, agreed upon, realistic and time-based. It looked reasonable and everyone agreed to these goals. I then sat back and observed, like one of the spectators quaffing champagne from the upland of the Chersonese as they gazed at the Charge of the Light Brigade.
The radical project instantly became the subject of fascination within the company, and the manager in charge found himself giving dazzling presentations to senior executives. I occasionally visited the development office. Bearded, scholarly developers were everywhere; workstations with vast windowing screens proliferated. The office was fitted out in gloriously contemporary fashion, with lots of expensive Danish furniture. Several university departments took an interest in the project, and it got a glowing write-up in the glossy Computer Mags, with a photo of the manager standing by a Unix Workstation, looking imposing and important.
Meanwhile, the conservative project was taken on by a rather anonymous, and unspectacular, outsourcing company, whose local office was a shabby place somewhere in the Essex mud-flats. The red-brick and asbestos building, with metal window frames, seemed to have once belonged to a jobbing engineering company. The genial staff had the appearance of middle-aged secondary teachers, but had a quiet and unflappable demeanor. I visited them once, but I strain to remember much about them.
After six months, the radical project had achieved some spectacular demonstrations, and reports of its progress were sweeping the industry. Breakthroughs had been made, 'new standards' created in user interface design. Their Artificial Intelligence system for doing the costing was acclaimed by many academics. And yet, in terms of real deliverables, the project wasn't making any tangible progress at all against the benchmarks. The project fell into a cycle of exciting demonstrations followed by agonizing delay.
By contrast, and to my enormous surprise, the team from the Essex mud-flats had delivered their project ahead of schedule: It was good, and pleased their users. It ran on existing workstations and was so simple to use that we saved a huge amount on our training budget. They’d even managed to introduce many of the GUI components on which the radical project had majored.
As the department awaiting the completion of the radical project began to gaze enviously at the completed conservative one, it became was clear what had to be done. Scrapping such an exciting project seemed like shooting one’s pet dog, but when the company finally decided to act, many in the team were incredulous. They had achieved so much, they all felt. Ultimately, however, they were like a team of actors who had attempted, and failed, to give the audience "Macbeth" when all they really wanted in the first place was "Charleys’ Aunt"
And so the radical project died, and both departments adopted the conservative application, without complaint.
What sticks in the mind, after all the intervening years is that the complex windowing technology that was being used was so tricky that almost any progress was seen as a glorious achievement. It is the very nature of a development framework that it aims to dazzle. The developers had entered a fascinating world of animated windows, transparent dialog boxes, complex grids, hierarchical graphs and the like. Once embroiled in this world, they got so engrossed in the detail that they didn’t spot the painful fact that they weren't delivering tested functionality to reasonable timescales.
One can easily be led to believe that if a framework is hard work, but looks 'sexy' when mastered, and the developer breaks into a sweat, then progress is being made. The problem is that the intrinsic appeal of a technology can distract a team from heading in a single-minded way to the goal of a deliverable solution. However visually-appealing a technology is, it has, in the end, got to save time for its customers, and be more efficient to use than the system it replaces. That, surely, is the Conditio sine qua non