By the late 1990s the Web was growing up. Companies no longer wanted just a few attractive web pages; they wanted systems that could manage large amounts of information, allow staff to update content themselves and remain reliable enough to serve thousands of visitors every day.
I attended a Network Building course near Old Street, because one of my first tasks at the Garrick Corporation had been to install a windows peer-to-peer network and Eudora email system, not knowing anything about managing such systems. Both operated well, but I knew I had been lucky – things could have gone badly wrong – so I wanted to be prepared the next time. I also continued with some contract work and applied for a few full-time positions.
I was offered three different jobs in London. One was with a web design company, another was with a commercial media organisation, and the third was with the Institute of Physics. Although the salary was lower than the others, the Institute appealed to me because it seemed to offer the greatest opportunity to learn and experiment. Looking back, it was probably the most important career decision I made.
The Institute’s web infrastructure was based at the Institute of Physics Publishing offices in Bristol on Linux, Apache, Oracle and MySQL (later, PostgreSQL), using Perl to generate dynamic web pages. Until then I had never written Perl, and I had certainly never used the vi editor. Fortunately I was surrounded by some exceptionally talented colleagues who were always willing to share their knowledge. Peter, the go-to Perl guru, in particular, patiently introduced me to Perl, mod_perl and the way the Institute’s publishing systems worked. Before long I was writing production code myself.
One of my first major projects was to design and build what became known as the BDG Tools – an online system used by the Institute’s branches, divisions and groups to maintain their own web pages. Today it would simply be called a content management system, but at the time very few organisations had anything similar. The aim was to allow physicists around the country to update their own information without needing to understand HTML or rely on the web team for every change.
The first version worked well, but it also revealed something important about human nature. The different groups soon discovered that by changing the parameters in the page URL they could view and even edit each other’s pages. Most of it was done in good humour, with one group quietly correcting another group’s mistakes, but it was obvious that the system needed tighter controls. I quickly redesigned it so that the important information was hidden from the URL and checked securely behind the scenes. It was one of my earliest lessons that, if users can find an unexpected way of using a system, sooner or later they will.
When the system finally went live it proved remarkably successful. Instead of maintaining hundreds of static pages ourselves, responsibility was shared across the organisation while the design and navigation remained consistent. It also taught me another lesson that has stayed with me ever since: reliability matters far more than cleverness. Users soon forgive a system that looks ordinary, but they rarely forgive one that fails when they need it.
While all this was happening, in 2000 the Institute of Physics Publishing received the Queen’s Award for Enterprise in International Trade, recognising its success in exporting British scientific publishing around the world through innovative use of web technology. I attended the Award ceremony, but I was only a small part of a much larger team, responsible primarily for the user interface and front-end systems. It was rewarding to know that the work we were doing contributed, in however small a way, to that achievement.
Not long afterwards another challenge arrived. New accessibility standards from the World Wide Web Consortium (W3C) meant that large websites had to become much easier to use for people with visual impairments and other disabilities. My manager asked me to lead the initiative to bring the Institute’s website up to the highest practical accessibility standard. With six million pages, this was never going to be a quick task. I visited the RNIB, spoke with accessibility specialists and consulted the W3C guidance before drawing up a strategy. Achieving the very highest level proved unrealistic with the technology available at the time, but over the following years we successfully brought the site up to the second-highest standard. It was painstaking work, but it fundamentally changed the way I thought about designing websites. Accessibility was no longer an optional extra; it became part of good engineering.
Around 2002 the Institute purchased the neighbouring building, and one of the projects arising from the move was relocating the communications room. I volunteered to manage the migration. It was far larger than anything I had previously undertaken, involving Siemens engineers, relocating the telephone exchange and drilling large service ducts through the foundations linking the two buildings. Everything had to be carefully planned to minimise disruption, because the Institute’s communications depended on it. The move was completed successfully over a weekend, the only outage reported being one person’s loss of network through one overstretched Cat 5 cable in the huge bundle running between the two buildings. I received a Highly Commended award for the project. Shortly afterwards I was promoted to IT Manager.
One unexpected challenge was highlighted prior to the preparations during an installation of new servers. I arrived one morning to find water gushing from the wall onto one of the machines. The facilities manager explained that the building had a hidden world beneath it: old waterways, tunnels and pumps that kept the foundations dry. A failed pump had caused the leak. The problem was fixed quickly, and the server survived.
My network training came in very handy for supporting the complex connections between London and Bristol, and earlier experiences configuring Eudora email for the Garrick Corporation were useful when I migrated our existing email system’s account to Eudora using as my guide only a bulk load method described in the back pages of a badly translated manual. As part of my IT Manager role, I finally became responsible for acquiring, administering and configuring DNS records for our many domains.
Looking back, this was the period when I stopped thinking of myself simply as someone who built websites. I had become responsible for systems, infrastructure, projects and people. The Web was no longer a fascinating new technology on the edge of computing; it had become part of the organisation’s core business, and I found myself helping to build the foundations on which that future depended.
You can always find a full index of all the articles on the page under About me in the main menu.
Web Stories
Around 2002, I stayed with friends in Cyprus who had two young children. One afternoon I showed them the basics of HTML. We typed a few simple tags, saved the file, refreshed the browser, and suddenly there were colours, headings and pictures appearing on the screen.
Their reaction was unforgettable. They stared at the monitor in complete amazement. The idea that they could type a few lines of text and create something that anyone in the world might one day see seemed almost magical.
I remember feeling exactly the same when I first discovered programming years earlier. Technology changes, but that sense of wonder never really goes.
As far as I know, one of those children later became a web developer. Whether that afternoon had anything to do with it, I’ll never know, but I’d like to think that, for a moment at least, they experienced the same excitement that had first drawn me into the Web.
Occult, Sci-fi & Military 