Apostrophe’s cause problem’s in e-health system’s Australia’s bug-ridden PCEHR – personally-controlled electronic health record – has run into another first glitch, with its registration site reportedly rejecting names containing non-alphanumeric characters. If you’re an O’Dwyer or have a double-barrelled surname, the registration process for PCEHRs would have failed, …
for people like me who don't have a family name at all (there is no legal requirement to have one in this country and I chose not to have one long ago and had my legal name ammended to suit). Plays havoc with various incompetently-implimented government IT systems. Sucks to be them!
I was at uni with a bloke who changed his name to Wolf, dropping his family name (there was a big family conflict at the bottom of this that we never heard all of but it was nasty and he wanted nothing to do with them). The enrollment system could not cope with this so it gave him an initial. Thus he was A Wolf. He spent ages trying to get them to change it to "The"...
The crap I see every day attests to that. Allowing users to enter unsanitized data straight into databases is still rampant, enforcing the same business rules in different frontend PHP pages rather than properly centralizing them in shared backend classes, copy pasting of huge sections of code so you can "reuse it" because one variable needs to be different. These things are all endemic in your typical in-house developed business application these days.
The coders that are pumped out of our "degree factories" learn the syntax of a language but have no idea on how to properly structure their code or sanitize user inputs.
"Shared backend classes" my arse. What you mean is "opaque layers of dynamically generated files in which errors can only be detected by testing, and even that probably won't work half the time".
I'm prepared to bet that whatever technology Accenture threw at this project, it wasn't PHP.
but my experience has been that having too much is far harder to achieve than having too little, and actually doesn't cause as many problems. Granted that something about MVC seems to foster this kind of excess, and granted that something like Magento is no fun to deal with at all, precisely because it has been over-architected -- but I'd rather work with that, than with a system produced by some balls-out cowboy who's never heard of anything and so doesn't see why it's a problem to produce half-megabyte-long script files which promiscuously mix database calls, business logic, and rendering code, unrelieved by even the slightest hint of sanity or maintainability.
MVC and heavy backend architecture in general -- hard to maintain? Sure! I'd rather that than impossible. Wouldn't you?
This post has been deleted by its author
You have got to be bloody kidding me... a multi-million dollar system being coded by morons! How the hell does anyone working in such a situation not know better? Seriously! What the hell is wrong with these people!?
It's one thing to make mistakes like this when working on a $500 PHP website for the local footy club... but a multi-million dollar website for the federal government?
Despite the references to Bobby Tables and un-sanitized inputs, it's actually far more likely that the system was doing TOO MUCH sanitization than none at all, especially given that hyphens are apparently not allowed. Thus much more likely that the inputs were being scanned to validate that they only had alphabetic characters in, rather than no validation was being performed at all and that the system was then crashing with entries containing apostrophes and hyphens.
Still makes it a rubbish design and build but I guess I'd prefer a crap system with too much sanitization than a crap system with none at all.
More likely no sanitisation at all, effectively interpreting the minus sign and apostrophe as valid programming language syntax and failing due to the resulting syntax errors. Easy enough to check, but to answer your point, sanitisation that falls over when the input is not valid is not good programming practice either.
Why does this not surprise me? I've lot count of the number of websites that steadfastly refuse to allow me to enter my telephone number correctly, stubbonly just saying "not a phone number" until I guess that I have to enter a completely unpunctuated and unreadable string of digits.
I read up above in a comment that this is Accenture's doing - colour me something tastfully contrasting to surprised...
A story apostrophic, and not apocryphal:
When writing the pile-of-crap RITA system for the UKs RPA (Rural Payments Agency), they managed to sneak into a functional design a statement that an interface (related to printing customised forms and letters) would not use genuine XML, but rather something somewhat like XML.
Suffice to say, everything performed nominally for the new system (that is to say, it shat itself) whenever customer data included XML markup characters. Rather than fixing the problem by redoing it properly with an XML encoder, they string replaced the problem characters (like ampersand and apostrophe) using cludge search-replace scripts until it got through the test environment.
Of course, everything was over dead-line already, and when the first, well-overdue, live production run unsurprisingly went tits-up, (due to a single customer amongst the 100,000 with a greater-than symbol in it's name) it was blamed on the truly-hardworking team of civil servants in the department for obviously not testing thoroughly enough, Accenture were to be held basically blameless by the senior management; after all. they were the experts in technical implementation - my suggestion that they might be incompetent and deserving of a firm legal spanking seemed only to result in more fire coming in our direction...
Anonymous, because I'm embarrassed I didn't pick up the glitch was still in the functional design until too late... (ie: post-signoff, once requiring something trivial to be fixed meant tens-of-thousands-of-pounds of change request)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
