Helping others with software design
Prescriptive help has its place in organizations, no doubt. Looking for other words for the prescribe verb come two groups of words with different connotation: dictate, rule, specify with authority, decree, force, control, ordain, order, command, oblige. When there are precepts for the well being of any given organization, prescriptive points make sense.
The other group of words for it is: to direct, to fix, to guide.
I tend to think that Microsoft patterns and practices group’s intention for their work is aligned with the second group of words.
Sadly, I have seen overuse and abuse of their work by some organizations that uncontrollably misunderstand and distort that intention and go with the intention implied in the first group of words.
By this time, seem to be clear that this is a natural part of the way our industry behaves at its current infancy.
But there are of course groups of professionals that behave differently, they already know and sympathize with the following comment:
"As an engineer you have a responsibility to quantitatively understand the costs and benefits of your proposed solution. Using our design guidelines to focus and limit your choices to patterns which have historically proven to be good choices is a great way to focus your work and be more effective but it does not discharge your responsibility" -Rico Mariani
Perhaps a better word instead of “prescriptive guidance” could be “assistive” or “descriptive”.
Perhaps it is the connotation of the first group of words above that just does not feel right for software design. There are different feelings when reading something related to software design like the below fragment from “The Art and Science of Smalltalk” by Simon Lewis:
“It's not intended to give you a defined process that you can feed your problem into at one end, and have Smalltalk code come out of at the other. Sometimes, competing views of how things should be done will be presented. You'll have to decide which philosophy to adopt in your particular circumstances, but you will be making an informed decision. In this way, the book is not prescriptive, but instead it's 'assistive'. It's also not a tutorial. You are however invited—in fact you're encouraged—to try things out using the system. Smalltalk style supports this, and you should experiment whenever something is not clear, or you want to confirm or enhance your understanding.”