When Guidelines Should Be Descriptive or Prescriptive
Jens Meiert, September 13, 2008 / October 2, 2008.
This entry is filed under Web Development, Accessibility, Usability, Design.
Every time I’m setting up guidelines and standards, mostly within companies, one of the questions I need to ask and answer myself is whether or not they, or which parts of them, should be descriptive or prescriptive. For coding guidelines this would mean the difference between, say, “the markup should be valid” and “the markup must be valid” (think RFC 2119), no matter that the former is not per se descriptive but rather “recommending” some approach.
So when to recommend or describe something to be followed, and when to force and prescribe? This decision seems to depend on three factors:
-
The situation. Is everybody doing well, or is the situation rather bad? If it’s going well, then an approach based on strict rules might be best in order to support everything that’s already been achieved, and the guidelines might only require writing down formerly unwritten laws. If it’s bad, then recommendations, descriptive guidelines will work best to gently push into the right direction.
-
The goal. Is there a need to sensitize and establish some mindset and process first, having some time at hands as well, or is it desirable to maybe even quickly enforce certain rules, even when the results are already great? Establishing a mindset likely means going for recommendations, enforcing something requires to come up with clear, well-defined requirements.
-
The priority. Issues with a low priority might make it easier to abstain from strict rules thus giving some freedom, and critical items very well deserve more emphasis. Developing a set of coding guidelines, for example, that require lowercase letters for hex color values but leave it open to output valid CSS shows “interesting” priorities.
Let’s take the “valid markup” example from the introduction to make a decision for one item of some imaginary company’s coding guidelines:
-
The situation: Suboptimal. Nobody validates, formally valid output might only happen accidentally. How to handle a guideline about valid markup? Take the gentle approach: “The markup should be valid.”
-
The goal: Have valid output as the prerequisite to develop and improve the company’s websites. Changing the guideline? “The markup must be valid.”
-
The priority: Low, observing that the imaginary company uses elements according to their semantics, and that only few accessibility issues have been spotted. Changing the guideline? Depends on the value of the goal, philosophy, and quality entitlement; if it was me, I’d stick with “the markup must be valid.”
So the “descriptive vs. prescriptive” problem is not just known among linguists talking grammar, it clearly exists in our industry as well. As a sometimes lazy or even lousy writer I might miss some opportunities to make a better point here, especially why it’s so important to know about this situation, but I hope that at least one thing came through, namely that “descriptive vs. prescriptive” is something we might want to keep in mind anyway.
This is likely to be the last post I publish during my stay in the U.S. – taking a few days off now –, but the next one shouldn’t take more than one and a half weeks to follow. Meanwhile, consider taking a very short survey if you didn’t already (thanks to all who already casted their vote!), or enjoy some all-time classics 
Read More
Enjoy the most popular posts, probably including:
Comments
-
On September 15, 2008, 8:59 CEST, lup4lz said:
Comparing development guidelines with the descriptive/prescriptive grammar debate is dangerous.
Prescriptive grammar is always been a losing battle: languages change regardless of grammar rules while descriptive grammar is the science of observing the way people use language.
Any guidelines concerning a web development are instead there for specific reasons. They may help control the costs of current or future development of the site, the interoperability of software and portability of data as well the possible changes in the environment where the website or application needs to operate.
It’s easy to enforce loose guidelines in a small team but in a more complex project they should be formalized together with the reason why they exist. This way a developer can make an informed decision on when the guidelines should or should not be followed. This way you could take a guideline as a rule that can be bent as long as you know why you are doing it and are aware of the implications of the decision. -
On September 30, 2008, 18:13 CEST, Jens Meiert said:
lup4lz, thank you. Despite the concerns you raised I do think that the notion of “descriptive” and “prescriptive” should be kept in mind (and that it is helpful) to make a more informed decision on what to apply in a certain context, and to surely provide reasons as well.
