DX Infrastructure Manager

When Is Technology Not the Solution?

By Steve_Harvey posted 10-26-2017 04:16 PM

  

I recently came across a project requirement calling for an encrypted version of a VOIP protocol; I couldn’t fulfill the request, because the software didn’t support encryption of the protocol. However, I was able to resolve the issue by asking a simple question: “Is encryption an actual security requirement or is the possibility of encryption driving the request?” The latter was the case, and the issue was resolved.

 

That scenario got me thinking about a similar experience I had a few years ago, before I joined CA, that also illustrates how we can get so enticed by the lure of technical possibilities that we abandon practicality and common sense. I often tell the following anecdote because it shows how we can fall victim to techno-think that impedes—rather than facilitates—success.

 

I was asked to join a project that had been running for quite some time and had hit the bumblers because a key requirement had not been met. The customer had requested a GUI refresh rate of five seconds for a monitoring tool. Nearly 99% of customers request a refresh rate of 60 seconds, which was the default.

 

Five seconds simply wasn’t practical—or even possible, what with screen flashing/flickering and resources issues lurking in every corner. Nevertheless, the team had valiantly tried everything they could to make it work, to no avail.

 

My boss at the time asked me to see what I could do. Knowing that the chances of fixing this issue were very low, I had to think of a different approach. At my initial meeting with the team, the PM explained that the specs insisted on the five-second refresh rate. And there it was in black and white: a standard templated document with many boxes to fill, one of which said “Screen refresh rate: every 5 seconds.”

 

I said I would like to contact the architect so that I could understand the reason for the request. I was told he was a radar specialist and had returned to another unit of the organisation; they would call him for me.

 

That bit of information about the architect led me to put 2 and 2 together: At the time, typical CRT radar screens had a refresh rate of 5 seconds. I surmised that this was why the architect set this requirement, and that the requirement did not reflect the monitoring team’s operational needs. The architect confirmed my suspicion.

 

I was then shown to the monitoring suite and introduced to the two guys who monitored the systems on a 24-hour rotation. This got me thinking, “What happens when they take a break?” As you might expect, they stagger their breaks. I cheekily asked, “What happens when one of you is on a break and the other needs a bio break?” Looking a little non-plussed, one guy said, “Well, we just go.” The nearest rest room was at least a 3-minute walk away, so I estimated around 7 minutes for a round trip. If the 5-second refresh rate requirement were in effect, that would equate to 84 screen refreshes. When I pointed that out, they came to the realization that a 60-second refresh rate would be fine.

 

 My point—and I do have one—is that technical problems don’t always call for technical solutions; often, taking a wider view can solve an otherwise thorny problem. That’s something we should all remember in our tech-centric lives.

4 comments
2 views

Comments

11-15-2017 07:30 AM

Great article Steve - It just shows you that doing Tech for Tech for sake isn't always the right thing to do. Like James,  I always the why question, especially "why is this or that important to you"? This usually helps with understanding common sense. 

10-27-2017 01:51 PM

Hi Steve,

I am loving your blog posts and for me this is the best one yet!  What a great story and example of why we should ask "Why".  Just 'because' is not really a good answer

 

Regards

James

10-27-2017 04:43 AM

I too like your story and can relate to similar experiences in my distant past.

It should be the first thought to anyone creating a solution, can I change the requirements to make the solution easier?

It just takes one moment to step back and look at the requirements from afar and sometimes a eureka moment happens.

It is these little early decisions which can make the difference between a profitable/successful project and one which overruns and makes a loss.

Keep it up Steve!

 

 

10-26-2017 05:15 PM

Steve, a very insightful article.  I can't help but equate what you've stated to common sense.  When we get too close to something and perhaps develop tunnel vision, often the best thing to do is step back, use our common sense and ask ourselves if what we're thinking or doing is realistic and reasonable.

 

A shameless plug for sure, but in a recent blog I wrote, "The Jurassic Park Conundrum" (The Jurassic Park Conundrum), I discuss something very similar to what you've described.  It boils down to "should we do this" vs. "can we do this", and you've given a great example of how those can often be mixed up.

 

Thanks for a great blog.