Drop the assumptions, re-frame the question
More than two years ago, on 7 November 2011, I created a new card on our Trello board called “Fix memos on internal homepages”.
It then sat on the board for the next 24 months, and was not touched, apart from to shuffled around the board a bit, from one list to another: from ‘backlog’ to ‘this week’ to ‘backlog’ to ‘known issues’ to ‘backlog’ to ‘bugs’ to ‘known issues’ to ‘backlog’ before it was finally scheduled to be done four weeks ago, three weeks ago, two weeks ago, one week ago… this week.
In the end it only took about 30 minutes to fix!
The issue
The issue in question was this: if a user visited the current staff, current students’ or current postgraduates’ homepage (and a few other school websites) under a secure connection (https) then they were not able to read the memos or events. Instead, they were served an error message, e.g.
The problem
The problem wasn’t affecting too many people, either. We would maybe receive one complaint about it every six months, so there was no urgency. But we considered it a significant issue to keep it on the board. For two years.
The reason that nobody fixed the issue was, I suspect, two-fold:
- Fear
- Prejudice
Fear
We feared that this problem would be very complicated and time-consuming to fix. Our fear led to inaction.
It sounds like it should be a complicated thing.
It sounds like we should need to know exactly what happens at both the server and browser levels when content is served using Hypertext Transfer Protocol Secure (HTTPS) compared with a non-secure communication.
It sounds like we may need to delve into server configurations or look up obscure chapters in books about PHP security to figure it out.
We didn’t.
Prejudice
Each time we discussed that card (as we shuffled it around the board trying to settle on the best list on which to ignore it) we spoke vaguely about what we suspected we needed to do, rather than simply stating the problem we were experiencing.
We always spoke about this incident with a particular solution in mind. And that solution was one that had emerged from our fearful speculation rather than simply stating the facts about the problem.
“Oh, that’s the problem where we have to force the pages to be loaded as http rather than https, isn’t it?”
And we would all agree.
“We’re going to have to do that using either .htaccess or PHP, aren’t we?” someone would continue.
And we’d all agree.
But we were wrong.
Drop the assumptions, re-frame the question
At the start of the week, I volunteered to look at this card.
I already had our pre-conceived idea at the ready and so I immediately spent a couple of hours reading up on forcing https pages to reload as http using .htaccess files.
“Boy this looks complicated!” I thought. “Surely there’s an easier way.”
And it was only at that point that I suddenly realised what I was doing. Or rather what I wasn’t doing. I wasn’t considering the actual problem itself; I was leaping straight to a solution.
The problem wasn’t that these pages weren’t forcing the page to be loaded under http, it was that the memos and events wouldn’t displayed if the pages were loaded under https. That’s a whole different issue.
I rewrote the ticket in Trello to reflect this: “Allow memos and events to be viewed under https“.
I then wrote myself an Agile-style story:
- As a member of staff…
- When visiting the staff homepage under an https connection…
- I would like to view the events and memos, rather than an error message.
And it was at this point that I suddenly realised what the root cause of the issue was: the browsers were not pulling in the events and memos because they were hard-coded in the PHP and JavaScript files to be served under http.
So I changed these to protocol relative URLs.
Now, rather than referencing http://www.st-andrews.ac.uk/my-file.php I changed this to read //www.st-andrews.ac.uk/my-file.php so that the browser uses whichever protocol it’s currently receiving (see section 4.2 of RFC 3986 Uniform Resource Identifier (URI): Generic Syntax for details.)
And like I said, it took me about 30 minutes to update all six pages that were affected.
The lesson for next time: drop the assumptions, re-frame the question. Perhaps the answer is more simple than you first thought.