To be subjective is to allow your opinions to shape or influence your accepted perception and eventual decision making. Subjectivity is quite literally the opposite of objectivity which is
The act of being subjective is forced upon us any time we’re asked to come up with a(n) conclusion/answer where our only resource is our opinions or where we can’t:
- Experiment to draw the best conclusion or
- Weigh a restricted, easily distinguishable, set of options against one another or
- Pull from past experience to draw the best conclusion.
When it comes to designing, improving or changing solutions (of any kind)… always remember… subjectivity is kinda the devil.
Avoiding Subjectivity Like the Plague
Sure, there’s a time and place to allow, even encourage, subjectivity. Look at the image atop this post. Is it a sweet old couple gazing into each others eyes, or is it two men from different cultures happily sitting near each other discussing their differences? At the end of the day, it just doesn’t matter which opinion is more accurate than the other. Both are beautiful, pretty “glass is half full” scenarios. While it’s a healthy part of reflecting, or being philosophical, or learning to “Trial and Error” your way through things, subjectivity has no place in solutions built for use/consumption by your End Users.
Thank goodness Salesforce gives us some super simple ways to reduce or eliminate subjectivity on our solutions!
- Picklists (PLs)
- User’s Question – What value should I enter into this field?
- PLs reduce subjectivity via a restricted set of options that are clearly discernible from one another. Dependent Picklists take this to another level by further reducing said options!
- Validation Rules (VRs)
- User’s Question – Can I enter “this” value “here” in “this scenario“?
- VRs eliminate subjectivity by slamming the door on partial, missing, incorrectly formatted values, etc.
- Formula Fields (FFs)
- User’s Question – What value should be associated with this Record given the other values entered?
- FFs eliminate subjectivity by producing a very specific result. Their methods are unwavering and instantly yield dependable/repeatable results.
- Multi-Select Picklists
- Never mind. Upon closer investigation, these are also the devil.
When all is said and done, it’s all too easy to make bad choices. Bad choices almost inevitably lead to bad data and in many cases bad data can set off ripple effects that can be hard to spot and nearly impossible to stop. It’s worth noting that I’m using the word “bad” to imply that said choices could lead to: incomplete, inaccurate or incorrectly categorized data.
Like any system, you get out what you put in. Crap in, crap out.
Look for subjectivity. Constantly. Look for it while documenting requirements, when you’re finalizing your processes and before delivering any solutions. If you come across it, talk about it! Immediately explore its source and make its hazards known to the team. If the stage of your project in which you’re in at the time of this discovery isn’t conducive to problem solving, be sure to document your concerns in the parking lot.
As promised in my last post, up next in my series about a general methodology for facilitating the improvement/modification of processes… my next post will be about assembling the troops, mapping the current state of your processes, setting your scope and honing in on refined versions of your problem statement and requirements list.
Have questions or comments? Leave them below or hit me up on Twitter @SFDCGEEK.
Thanks for reading!