User:Kdf9andtd1a

Phil Runciman

Although qualified in Mining Engineering, I commenced work as a Research Technologist at the Mechanical Engineering Laboratories of English Electric programming for KDF9. This was in January 1966.

Edsgar Dijkstra's notes on structured programming had influenced the programmers at Whetstone, so it was that "structured programming" concept was initially the concept of factorising the problem into its discrete components, rather than only omitting "goto statements".

Access to the excellent company library at this site was highly valued.

It was here that my interest in the MIS problem and the use of DBMS as an enabling technology was piqued.

I learned basic real-time programming concepts working on the Wylfa power station's alarm monitoring system.

The parallels between the KDF9 operating system and manufacturing operations scheduling were not lost on me. Seeing KDF9 as a factory for the efficient processing programs was a powerful idea. The preprocessing of the incoming job stream, to optimise the throughput of "load and go" jobs, was a simple but advanced concept.

I learned basic real-time programming concepts working on the Wylfa power station's alarm monitoring system.

On Wylfa's TAC computer I had a computer to myself.

I was later drafted in to help the ESRO TD1a Satellite Programme. As a checkout programmer, having to meet very tight dead lines, my skills in quickly factorising problems and code writing were honed. Understanding everything from the bootstrap loader, the layout of the whole system's programs in memory, and the way the linking loader worked to assign memory resources to the various modules was a heady experience. Understanding the dynamics of the operating system kernal from the interrupt skip chain onwards is a privilege too few people get these days. Only my time at Plessey, Poole came anywhere near to this for sheer enjoyment. It was here that I discovered that more memory did not always equate to more throughput! Systems have their own properties. Sometimes these are unexpected.

The ESRO TD1a checkout programme was fun. The checkout philosophy involves a "battle" between the engineers and the programmers. Sometimes the program is correct and the engineers modify the hardware. Sometimes it was the other way around. It was always fun.

So now you know why I call myself KDF9andTD1a. It is in honour of one of the world's truly great computers and Europe's first astronomical research satellite. (My wife's cousin was responsible for its primary experiment and for the creation of ESRO itself.)

Since these formative years my interests have always been driven by the notion, "There has to be a better way." This together with the appreciation of the impact of company culture on its behaviours (Thanks to Ron Ingham, a work colleague who founded the CCTA, UK) has driven me inexorably towards the "Agile" approaches and finding ways to eliminate their shortcomings. Sadly, life is too short.

Career low point: being engaged to support a "waterfall" methodology, while wanting an iterative approach.

Economics and its side effects, have all too often undermined progress in computing and indeed other spheres. I applaud Wikipedia's efforts in providing a vehicle through which some of these effects may be mitigated.