Archives
Reuters technical development chronology 1964-1990: Introduction
Monday 22 June 2015
This first instalment of the chronology is published in five parts, each covering half a decade, and spans the period from 1964, at the very beginning of the technical development function in Reuters, to 1990 and the retirement of its champion, managing director Glen Renfrew.
For a member of technical development during this period, Reuters was largely an exciting place to work. The work was interesting and technology choices for product development were relatively straightforward instead of a confusing array of possibilities. Product development required that technical boundaries in terms of communications, hardware and software be pushed to the limits. There was time to do things within reason and although many of the larger undertakings were late to market, it didn't matter too much, and the product ideas seemed appropriate to the customers. If technology was not available to do the job or was too expensive then a solution was designed and built in-house. There are countless examples of this. No problem seemed insoluble. Reuters developers were often ahead of suppliers in understanding new technologies and their application. Products were understandable to the average staff member and not obscure entities requiring deep market knowledge. Products were designed and built to very high standards in terms of availability, speed, accuracy and extensibility. These attributes were ingrained in the thinking of technical development designers.
No problem seemed insoluble. Reuters developers were often ahead of suppliers in understanding new technologies and their application
The ability to extend the systems to meet increasing traffic rates and connection of new customers fuelled the growth of the company. Monitor, Dealing and IDN exceeded the original design targets by many orders of magnitude. Although technology and communications improvements helped it was really the excellence of the designs that allowed this effortless and cost effective expansion. It is easy to take this aspect for granted but it took a great deal of skill to continue over decades to satisfy the expectations of the company.
Apart from Michael Nelson, general manager, and Renfrew (who died on 29 June 2006), names in the chronology have been omitted. It would have been too easy to forget some vital contributor and in any case development is largely a collaborative venture with few stars. The content derives from the staff magazine Reuters World, personal recollections, the several books written and some papers of the day that had been kept.
The Reuters archives were also consulted and the two general chronologies by Jack Henry and John Entwisle were invaluable in adding to the story. The archive also provided some of the pictures used. The article will undoubtedly contain errors and omissions. Further comment and input is encouraged and will be incorporated in a future revision. Contributors are acknowledged at the end of the article. I am particularly grateful to Trevor Bartlett who has borne the brunt of the reviewing and has been a never-ending source of helpful suggestions and knowledge.
This first part starts with major development initiatives on hardware and communications with software very much in the background. By the end of the period in-house hardware and communication development had disappeared to be replaced by the configuring of off-the-shelf purchases often using external expertise. Software development still reigned supreme with large internal development organisations.
The next part will cover the 1990s which has an entirely different feel to it as the product problems become more difficult to solve, the pace of technical change increases, the external competition becomes more challenging and the commercial Internet starts to influence and confuse design thinking. Greater emphasis was placed on “buy don't build” and so more reliance placed on suppliers. This was inevitable and appropriate. After all, who would make their own PC, design their own operating system, write their own database, etc? It is, however, easy to then lose control of product development by only being able to move at the pace of supplier innovation. The trick is choosing the right supplier and drawing the line between supplier and in-house development in precisely the right place. The rapid growth of the company in the 1970s and 1980s with the many acquisitions had left a proliferation of systems, networks, products and product variants. In addition the external purchase of small entrepreneurial companies would be encouraged for parochial as well as marketing reasons which completely changed the nature of the software management problem. Communication between development groups using long standing relationships would no longer be enough.
All these areas would need to be addressed.
A few thoughts on technical development which have resonated during the compilation of this chronology:
Conway’s Law: This states that organisations that design systems are constrained to produce designs that are copies of the communications structures of those organisations. We will note in the text from time to time how this affected product development in Reuters as geographical and other passing organisational forces prevented good architectural solutions.
Fred Brook’s classic book on software development, The Mythical Man Month, refers to the phrase on the menu of the famous Antoine’s restaurant in New Orleans:
“Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.” In other words, as applied to development activities - do you want it now or when it works? Mostly Reuters was patient in managing the development function and was rewarded with good outcomes.
Finally, a lesson learnt over the years:
Complex functionality or infrastructure postponed into phase two rarely if ever sees the light of day.
■
- « Previous
- Next »
- 3 of 18