Elaine’s story: Exceeding user expectations

In 1993 I worked for a well-known shipping company and was stationed in Singapore, implementing an IT Business System across South East Asia.  The Internet had arrived, but was not yet reliable and businesses spurned it in favour of dedicated point-to-point leased lines for data transfer.

These were the very early days of EDI, and the Port of Singapore Authority (PSA) was in the forefront of developing standards for the exchange of electronic messages with customers and ship operators. They could see that efficient data handling was crucial to their mission to become the biggest transhipment port on the planet. However, the major ports were all in keen competition and each one was intent on designing their own systems. As a result a right royal mess of disparate interfaces and standards prevailed, and so for smaller operators, and those who were unwilling or unable to develop compatible systems, a portal to the PSA was available into which, as a last resort, container numbers and other relevant data could either be manually typed, or files in a special format could be uploaded.

Our largest ships of that time on what we called the Far East Trade routinely called at Port Klang in Malaysia to exchange cargo before the main call in Singapore.  Strict deadlines for the submission of cargo manifests were enforced by the PSA, but the short transit time from Port Klang to Singapore – around 24 hours – meant that some dispensation had to be given since the data were not available until just before the ship sailed. But the pressure to get the data submitted was enormous.

I met Elaine during a routine visit to Port Klang whilst becoming familiar with my patch. Part of Elaine’s role was to ensure that an accurate container loading list was sent to the Port of Singapore Authority (PSA) before the deadline set by them, based on the ship’s arrival time in Singapore. If the transmission was late then the ship could be delayed, and that meant big trouble. There would inevitably be a knock-on effect on the schedule, and the ship’s schedule was sacrosanct.

I was chatting to Elaine about her job whilst at the same time wondering why she looked so exhausted. It turned out that for every ship that called in Port Klang, she was single-handedly reconciling a printed list of several hundred container numbers sorted by location number from the local Port Authority, with another list provided from the ship operator, but sorted by destination, before entering them into the PSA portal. This took her several tedious hours of checking lists and crossing out matching items for each ship and, as the ships normally departed late at night, this kept Elaine up until the early hours of the morning two or three times a week – a fairly gruelling schedule.

I asked Elaine if electronic versions of the printed lists were available from the relevant parties. She wasn’t sure but when I got back to Singapore I made some enquiries and it turned out that they were easy to obtain, she had just needed to ask.  I asked them to provide some file samples, which duly arrived.

Now remember that these were the good old days: no coding standards, change control committees or mandatory software development processes to speak of.  Whilst the “real” software developers were building huge and unwieldy applications on IBM main-frames or AS/400 boxes, bright and IT-savvy employees with either a burning desire to improve their lot, or possibly with too much time on their hands, took it upon themselves to fill the gaps left by monolithic corporate IT systems with their own little home-grown PC spreadsheet and database applications.

For my own enlightenment I had just bought a version of Microsoft QuickC, a self-contained development tool which ran under MS-DOS (look it up!), had no inbuilt database connectivity or networking capability, and was generally extremely limited in functionality. But it did allow the deployment of code in standalone executable binary files, and in common with most computer languages was pretty good at reading and writing data files and sorting data. For this task, that was all I needed to be able to do.

I would blush at the code now, but I knocked up a QuickC application over a weekend that took the two lists, sorted and merged them and output a file that could be directly uploaded to the PSA through the portal. On my file samples it was able to do this in under ten seconds.

I took the opportunity of another trip to Malaysia to see Elaine and show her the software. She didn’t get it at first. We test ran the program a couple of times whilst I went through the steps. Then she went very quiet and I saw a tear rolling down her cheek. She got it now alright. Those late nights were now a thing of the past.

Now, I would love to be able to say that my career in software development has been filled with many moments like this.  It hasn’t. Users have become more sophisticated and more demanding and rightly so. But occasionally we are able to pull something off which greatly exceeds their expectations, and that is immensely satisfying.

Which is why I love working as a software developer for Vanilla Solutions.

JohnDuffy_squareJohn Duffy

Senior Technical Consultant

John joined the Vanilla staff in 2015, having worked with us as a freelance developer for several years previously.  John’s passion is turning a customer’s specification into a working software application and his skills with PL/SQL and .NET reliably produce results that exceed customer expectations.

If you need John’s assistance,  click here to contact us today

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *