5 ways to reduce advertising network latency

D'oh! This column has generated a lot of feedback, some indicating that the answers to the problems were obvious. Quite right - they are obvious to people with years of practice, and some of our readers are blessed with that experience.

But the whole point of the series is that none of us start with 20 years of experience. We all have to build it up, and one way to shortcut the process is to learn from the experience/mistakes of others. By sharing the errors of our early years, as John Rushforth shared his with me, we reduce the time it takes to gain the knowledge.

One case where I was singularly dim occurred not long after I entered the fray as a consultant. I was called in for the fairly routine work of looking at a Business Intelligence (BI) system, but I was a little surprised when I was told by the project manager that there were no problems with the system: it just needed a "health check".

So I started to audit and document the system but was constantly interrupted by the project manager poking his head around the door and asking: "Have you found anything odd yet?" The response: "No, what sort of odd thing should I have found?" was met with the totally unconvincing: "Oh, nothing... It's fine."

This, of course, served only to convince me that something was rotten in the state of BI, so I started digging.

My spade work uncovered a development bottleneck in Extract Transform Load (ETL). It transpired that the sole developer who could use the ETL software had somehow managed to establish as a precedent that all new routines took a week (40 hours) to develop, irrespective of their complexity.

Nobody had challenged this assumption initially and, over time, it had become an accepted part of the way the system operated. As soon as I raised this issue with the project manager his face lit up, but all he said was: "Really! Is a week too long for that kind of work?"

I had already gathered that I wasn't there for the health check, but at this point I realised I was the hatchet man.

The technical solution to the problem was straightforward. As a consultant one huge advantage is that you are allowed to trample all over established conventions because you (allegedly) don't know of their existence. So, as part of the "health check" I took the most complex ETL request from the backlog, went back to my hotel room that evening and returned to the company next morning with a fully finished routine - as you will have guessed, these were not complex extractions at all.

HR issues

This gave the project manager the opportunity to broach the unbroachable: armed with the evidence that a routine could be built in four hours it was easy to say "Right, we want this backlog of 20 routines completed in a fortnight. Thank you", leaving the developer with the choice of shaping up or shipping out.

As I got to know the company better, I could eventually ask why I had been given the wrong remit. It turned out that the human resources department had been consulted about the developer and had deemed that calling in a consultant to "spy" on a specific member of staff could be seen as harassment in any subsequent tribunal. However, a health check that uncovered a problem was perfectly acceptable.

So, despite my initial thoughts, it turned out to be just another case where a consultant was called in because something had gone wrong - I just wasn't told what the problem was. I learned that the true motivation for calling in a consultant is sometimes concealed, and that consultancy work is not always about technical issues. ®

5 ways to prepare your advertising infrastructure for disaster