"I could build that in five minutes!"
By @edent
· accessibility usability · 11 comments · 300 words · read ~1,182 times.
It's rather dispiriting when you launch something, only to have people berate you for not launching sooner.
A few months ago, I was involved in a medical questionnaire launch. Before it was released, I had several people send me polite (and not-so-polite) queries as to why it was taking so long. "I could build that in five minutes!" was the common refrain.
Some people, dissatisfied with our progress, did just that. They quickly built their own questionnaires and opened them to the public. That's the joy of the Web - you don't need to ask anyone's permission to publish. Some of the questionnaires were pretty good - but many were not.
Here are some of the problems I found with things which people launched in five minutes. This is non-exhaustive, and lightly edited for anonymity. But they were all genuine problems that were found. The problems broadly fell into two categories:
Security
- Submitted medical data over http.
- Allowed anyone to look up a previous submission.
- Stored medical data on a shared webhost in the USA.
- Any user could edit another user's medical information.
- Invasive advertising tracking on the form.
- No mechanism to prevent duplicate submissions.
- Loaded 3rd party JavaScript without SRI.
- Vulnerable to SQL injection.
Usefulness
- Asked for information which wasn't medically relevant.
- Didn't ask for specific information which was medically useful.
- Questions assumed users understood medical terminology.
- Used free-text boxes which another form control would be more suitable.
- Poor accessibility meant visually impaired users couldn't reliably answer some questions.
Just Five Minutes
It's really easy to build a form in 5 minutes. What takes the time is doing it right way.
Most of the time, getting the wrong answer quickly is not as useful as getting the right answer slowly.
Geza says:
Wow, you just described my life in a blog post 🙂
Jobsworth haha
This mindset is a massive problem even in healthcare where you'd think people would be a bit more switched about insecure HTTP, SQL injection, and the rest
Yep, the start of the technical debt mountain
A reminder that the problem with quick and dirty is that dirty remains long after quick has been forgotten.
Isabel says:
Thank you for constantly waving a flag for users like me with little or no sight. It's very much appreciated.
I love this post.
Rule of thumb, people asking "how hard can it be?" are normally saying "I’ve no idea how hard this is".
the hatter says:
None of the building correctly you describe even adds substantially to the five minutes. What it comes down to is already having the full domain knowledge, or at least understanding that you don't, and working with someone who does. Frankly, you probably could have built and released yours quicker, but turns out the people with this experience aren't always as available to put the time in, because these skills have value and are in demand. There is also value in sitting on what you've done and thinking about the current completed product/section before deciding either it's good, or actually you could do a bit or a lot better, with the value of hindsight, rather than just pushing it out of the door (or more formally, testing it - internally, and end-user)
Disclaimer: I know nothing of you, your product, or medicine. I do know web development and infosec, and a bit of the overlap into GDPR, HIPAA and similar caretaking schemes.
And they could. And some of them did. And, as @edent points out in some of his 'lightly anonymised' examples (and as have we on occasion, albeit a little less politely) they have broken the #law.
#MoveFastDOESBreakThings, so take care...
Applauding: A worthy companion to the 'it took many decades to learn how to do this' meme.
Love this post.
I found this lots in a previous role. Esp. the “well, I know a friend/contractor who has done this for X in half the time, so why would it take you so long?”.
No thought on legacy, integration, security, re-use of data etc.
The thing that really bugged me was the inevitable (after a separate bit of functionality like this was built): “Why won’t your original system integrate with this? You’ll need to replace/re-write it..”
Inspiring story I might quote whenever someone proposes a quick and dirty solution w/o security, testing, logging, monitoring and/or an acceptable level of maintainability shkspr.mobi/blog/2020/08/i…