Hidden Requirements

This AntiPattern comes into play when system requirements are not adequately documented, either through carelessness, ignorance, or malice. HiddenRequirements often arise from use of SpecifyNothing; In extreme cases, SpecifyNothing can be used as an excuse to retroactively create HiddenRequirements in order to sink a project or damage a career ('Your subsystem doesn't implement the XYZ protocol?!? What do you mean, you "didn't know it was supposed to"?').

[Note: This particular malady is easily defeated with an approach such as DesignByContract.]

If your work site is not amenable to advanced practices, getting things in writing is a big help. Not only does it help the recipient to be sure what to do, but the intimidation factor of getting an email that "here is what I understand the task to be" often gets the hider to come clean with requirements.

If nothing else, it is good to be able to say: I sent you ten memos from August 10 to November 15, and you never mentioned the XYZ protocol once in your responses.

Unfortunately, as we all know, MemosSlowDownDevelopment, even though MemosProtectTheSender?.

Perhaps that is true for full time, captive employees, but consultants need to employ these measures profusely. Nobody at the client's site is there to protect me. I am on my own.

Of course, it helps to ask to see the architecture, design, and implementation notes before getting into a peat bog. If nothing has been written down before I am asked to start then I need to insist that I do some writing myself to make sure everybody is singing from the same hymnal. If management says there is no time for that then I need to decide if this is really a job worth doing.

-- MartySchrader

CategoryAntiPattern, CategoryManagementAntiPattern, CategoryDevelopmentAntiPattern