Back to newsletter 150 contents
A colleague at a large enterprise related to me the following tale: "I had a problem with two servers being unable to connect to each other. So I called the helpline and reported it. At the same time, I called a friend I know who works in networks in a different organisation. My friend asked me for the output of ping, then tracert (it was a windows box), and finally ipconfig, and instantly told me what was wrong. Diagnosis time, 1 minute (at most)."
"In comparison, the helpline logged the issue, and raised a trouble ticket; after an hour there was no progress (it hadn't even been assigned), so I called and 'expedited' it. That meant it got assigned to someone (on a different continent). As I could view the ticket, I kept track that way. Over the next half day, it was reassigned, but no actual progress was noted on the ticket. The reassignments moved it slowly across teams - I think it was originally assigned to one type of communications team, but moved along teams. The next morning, I directly contacted the person now assigned (a network engineer in another continent). I'm not sure what had been done up to then on the actual problem, but he asked me for the output of ping, then tracert and ipconfig and finally route print. Then he came back to me - nearly an hour later - with a colleague. They asked if I knew how to fix some arcane aspect of the network setup (I didn't - and no, it wasn't the fix that my friend had suggested after his 1 minute diagnosis). They then went off to discuss the issue with the Windows support guys. Half a day later, after several reboots (and I assume several attempts at changing network configuration) the connection problem was still there. The help team then escalated it internally - I have no idea what that meant. Finally, late on day three, the correct fix - yes, the one originally suggested by my colleague - was applied and connection between servers was enabled."
"Yes, I could have suggested what the possible solution was to the helpline, but I've been fascinated for some time by the difference in capability shown by most of my colleagues and the 'cheaper resources' who the bean counters are increasingly shifting more and more of the enterprise IT tasks to. This was the first time I could actually directly quantify the difference. We've been told internally that these 'cheaper resources' are a fifth of the price of people like me. My network colleague, being an expert consultant for hire, probably costs twice what I do, so he's 10 times the cost of the 'cheaper resources'. So even if I exaggerate how much time his suggestion would have taken to fix the problem to a whole ten minutes (including a reboot), I can say that he would have taken ten minutes compared to about 60 hours of elapsed time that actual solution took; and even assuming that no one other than the five 'cheaper resources' that I directly know about were involved; and that they were all working on the problem at separate times, so equivalent to one person; and that only a total of five hours was actually spent on the issue; I still estimate that the 10 minutes of would be cost for my colleague actually cost 300 minutes of the 10x cheaper resources. In other words, by taking the worst case cost of my colleague and the best case cost of the 'cheaper' solution, I estimate that the 'cheaper' solution was 3x more expensive, and took much much much longer in elapsed time."
I found that tale fascinating, so decided to share it with you. I have no knowledge of how representative it is. As someone who emphasizes that you need to measure the benefits of each change, I found it an interesting comparison. But the only lesson I learn from it is one that I've known for a while: that experts - wherever they may be - are hugely more productive than everyone else, and are worth their weight in gold. Now on to all our usual links to Java performance tools, news, articles and, as ever, all the extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 150 contents