When Guidelines Should Be Descriptive or Prescriptive
Published on September 13, 2008 (ā» February 5, 2024), filed under Web Development (RSS feed for allĀ categories).
This and many other posts are also available as a pretty, well-behaved ebook: On Web Development. And if youāre only interested in a robust overview on coding guidelines, check out my little book on it: The Little Book of HTML/CSS Coding Guidelines (updated).
Every time Iām putting up guidelines or standards one of the decisions I need to make is whether the guidelines, or which parts of them, should be descriptive (positive) or prescriptive (normative). For coding guidelines this could mean the difference between, say, āthe markup should be validā and āthe markup must be validā (think RFC 2119).
The question is when to recommend or describe something to be followed, and when to force and prescribe? In my mind this decision depends on three factors:
-
The goal. Is there a need to sensitize and establish a particular mindset and process first, and is there sufficient time as well, or is it desirable to quickly enforce certain rules, even when the results are already solid? Establishing a mindset suggests to go for recommendations first, enforcing something to come up with clear requirements.
-
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 create support for everything thatās already been achieved, and the guidelines might only mean written testament of formerly unwritten laws. If the situationās bad, then recommendations, descriptive guidelines may work best to push into the right direction.
-
The priority. Low priority issues donāt need to be treated with strict rules right from the bat; they can allow for some flexibility. Only critical issues may get all the attention. Coding guidelines that require lowercase letters for hex color values but leave it open to use valid CSS exhibit an āinterestingā sense for whatās important.
Letās take the āvalid markupā example from the introduction to make decisions for a few imaginary companiesā coding guidelines:
-
Company 1, the goal: Have valid output be the prerequisite to develop and improve the companyās websites. Changing the guideline? āThe markup must be valid.ā
-
Company 2, the situation: suboptimal. Nobody validates, valid code only appears accidentally. How to handle a guideline about valid markup? Take the gentle approach: āThe markup should be valid.ā
-
Company 3, the priority: Low, observing that the 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 go for āthe markup must be valid.ā
As we can see, the ādescriptive vs. prescriptiveā problem is not just one for linguists talking grammar. Itās of relevance for our industry, too. I may have missed opportunities to make better points but I hope that the main point came across, namely that ādescriptive vs. prescriptiveā is something we need to keep in mind.
This is likely to be the last post I publish during my stay in the U.S.āIāve been taking a few days offābut the next one should be out in one and a half weeks. Consider taking a very short survey if you didnāt already (thanks to all who have already casted their vote!), or enjoy one of the all-time classics š
About Me
Iām Jens, and Iām an engineering lead and author. Iāve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, Iām close to W3C and WHATWG, and I write and review books for OāReilly and FrontendĀ Dogma.
With my current move to Spain, Iām open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedInĀ profile.
I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views andĀ experiences.
Comments (Closed)
-
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.
Read More
Maybe of interest to you,Ā too:
- Next: The Most Important Thing Is to Get the HTML Right
- Previous: How to Share Code With Users
- More under Web Development
- More from 2008
- Most popular posts
Looking for a way to comment? Comments have been disabled,Ā unfortunately.
Get a good look at web development? Try WebGlossary.infoāand The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, andĀ Leanpub.