“Training Issue” Is No Parry Five

Some developers think the words “Training Issue” are a parry five when it comes to defect resolution. The developers will mark the issue as resolved/won’t fix or some such nonsense, brush the crumbs of QA intransigence from their hands, and go back to voting for the Nintendo Wii over the XBox in an Internet poll.

I don’t know where the developers got the idea of this mythical training upon which they hope to rely to cover their deficient code; none of the places for which I’ve worked or contracted in this century have had actual training departments. Or much of a documentation department. So the developers who deploy the “training issue” defense really mean that a) This issue will be brought up in the 30 minute demo with the check signer where the check signer decides whether to sign that check or b) They really, really hope that a user doesn’t find it or c) “Training Issue” means “customer support issue.”
No, those developers who deploy the “Training Issue” tactic often use it to defend the fact that they don’t build in common-sense data validation, such as allowing the users to enter end dates that are earlier than the entered start dates or allowing users to enter strings where numbers are expected; in any event, the application passes bad data into the database for someone else to deal with somewhere.

A couple lines of code and there wouldn’t be a “Training Issue” to leave unmentioned, undocumented, and certainly untrained to the poor, unsuspecting users from the deadline day forward forever.

Just so the developer can spend more time before lunch talking about the how soon Senjo No Kizuna will come to America instead of writing in boring validation code.

So remember, ungentle reader, that “Training Issue” is not a valid response to an issue, as only the last part, “Issue,” is true, and the first part, “Training,” is a complete and utter fabrication.

Comments are closed.

wordpress visitors