Junior Programmer

In 1980, having just completed his Bachelor of Science studies Auckland University, Geoffrey took a position as Junior Programmer in an Auckland company, Automation Engineering (AE). At a time when the I.T. industry was dominated by COBOL programmers writing and maintaining payroll programs for I.B.M. mainframes running in batch mode, AE was developing both large and small scale computer systems for industrial process control using structured high-level languages including Pascal and running on architecturally appealing Digital Equipment Corporation (DEC) PDP-11s. They were also pioneering the use of microprocessors in control systems, rather than the relay-dominated logic systems then prevalent. This was leading-edge technology and the allure was irresistible.

"Microwet"

Geoffrey's first project was a microprocessor-based irrigation controller, and his implementation included an interrupt-driven, pre-emptive scheduling, multi-threaded operating system kernel with semaphore-locking of shared resources, together with multiple layered application-dependent processes, all within 6 kilobytes of system ROM, a quite remarkable feat. The controller, prosaically dubbed "Microwet", was a commercial success.

The Tomoana Project

He then joined a software development team of six working on a most ambitious project that sought to automate many of the data acquisition and product handling tasks of what was the largest sheep processing plant ever to operate in New Zealand, the Tomoana Freezing Works of Weddel (N.Z.) Ltd, in Hastings. This project came to dominate his life for the next decade.

It was audacious in scope, with the design calling for the hierarchical networking (via 9600 baud serial lines!) of more than 20 Motorola 6800 microprocessor-based operator and hardware interface units, six DEC LSI-11/03s operating as data concentrators and default controllers, one LSI-11/23 to oversee the final product sorting stage, and a pair of PDP-11/34As to provide high-level operator control, order processing, reporting, and software development functions. Initial development took place in Auckland, with the team then being sent to Hastings for six weeks to install the system.

It soon became very apparent that flaws in the design and specification of the system had led to the development of software that could not possibly deliver a working system. Despite valiant efforts by team members to adapt what they had produced to the situation as it really existed, the six weeks passed without a viable system being established. Both parties to the contract realised that a point of no return had been passed, and that the only sensible course was to redevelop the software in situ, and in close liaison with the end-users, and that it was likely to be a long process.

Success

Over the next 18 months, substantial progress was made. With the departure of some team members, responsibilities for low-level system programming and microprocessor development fell increasingly to Geoffrey, in addition to his application programming duties. With them came the opportunity to eliminate what he considered to be the central flaw in the system design: the use of shared disk files as communications buffers among key processes. This paradigm was a hold-over from the batch-oriented world, but was totally inappropriate in a real-time interactive environment, especially given the absence of a formal database management system, the need for data synchronisation, and the slow speed of the disk drives then available. Instead, Geoffrey implemented a monitor approach, where a single designated process maintained the integrity of each set of functionally related data structures, including in-memory buffering of recent data and maintenance of disk files. All access to this data by other processes was channelled through the monitor process by the passing of messages, foreshadowing the server-client and object-oriented architectures that are so prevalent today.

With that foundation in place, the rate of progress accelerated, and a minimally functional system was finally put into operation. The resulting efficiencies allowed the Tomoana Works to pass two milestones, records which stand to this day: first, the processing of more than 20,000 sheep and lambs in one standard working day, and then the processing of 100,000 in one working week.

Crisis

Contractually, however, all was not well, and a stand-off developed between the parties: Weddel ceased payment because a complete product had not been delivered on time, even though basic functionality had been achieved; AE ceased work on the project because it was not being paid. The team was recalled to Auckland, and some months passed, during which, one of the strongest members of the programming team resigned, leaving only two with any significant knowledge or experience of the Tomoana system: an application programmer, and Geoffrey: application programmer, system programmer, microprocessor programmer, and de facto project manager.

This was a difficult time for him. His relationship with AE was becoming strained, primarily with the contrast between being a near-autonomous project manager one month, and being tasked to hunt software bugs at the Mangere Sewage Treatment Plant the next. Also, in large part as a result of his many extended absences from his home in Auckland, his personal and domestic arrangements were in turmoil.

Resolution

Geoffrey decided that his position at AE was no longer tenable and submitted his resignation, but he did so knowing that it would bring into existence a potential solution not only to the difficulties he faced personally, but also the contractual difficulties that existed between AE and Weddel. He telephoned the Weddel Senior Project Engineer, Mike Pownall, a man for whom he had great respect, and advised him that he had resigned from AE and was seeking alternative employment. An offer was not long in coming.

Geoffrey relocated to Hastings and went to work for Weddel charged with the task of finishing implementation of the project. Everyone's problems were solved: Weddel would have their system finished under their direct control; AE would be absolved of responsibility for this; and he would be employed at a much higher salary completing a project that only he could, and that having been his sole focus for some years, would have been very upsetting to have to abandon unfinished.