It is more important than ever for teams, apps, systems, and data to be connected. Come to our 90-minute user group to learn how top companies are using IBM webMethods to address challenging integration issues.
Each session will share a unique perspective on their journey, beginning with the obstacles faced prior to webMethods adoption and sharing the business outcomes achieved since implementation.
Best practices for overcoming integration challenges
How webMethods has been deployed to solve specific business problems
Benefits and improvements in performance, productivity, and innovation
In my quest to eliminate “best practice” from everyone’s communication, I offer that there is no such thing. There are many practices/implementations that multiple groups have used successfully in various situations. That does not make them “best.” Just possibly common.
The “in various situations” is key here. It is a nice way to bring context into the equation.
In my view the so-called best practices should be seen as a set of case-studies. If sufficient context is provided, it is possible to see how certain design and/or implementation aspects lend themselves well (or not) to a given situation.
All too often, unfortunately, this aspect gets lost in the quest for the infamous silver bullet. Then your best-case scenario can be seen, at best, as the lowest common denominator. But certainly not something that deserves the attribute “best”.
To be clear: I don’t know what gets presented at the event mentioned above. In that spirit my comments are meant as general remarks and not judgment of any sort.
Mine as well. I have no doubt that the material in the session will be very useful. My post is to advocate for calling that set of material something other than best practices.
Why can’t we agree that there is no such thing as best practice, but there can be best practices? Imo as long as it doesn’t dictate it is the absolute best, but it is one of the working and somewhat easy to implement and clean solutions, it is a best practice, not the absolute best, but one of them. It is plural in the OP, so it should be fine for this case.
The article I linked to provided a variety of rationale of why “best” as a label is to be avoided, whether it is a single “practice” or a collection of “practices.”
Early in the article:
there is no practice that is better than all other possible practices, regardless of the context. In other words, no matter what the practice and how valuable it may be in one context, I can destroy it by altering things about the situation surrounding the practice.
That article is primarily focused on “best” and its vagueness/subjective nature.
Who determines which practices are best? As I understand the evolution, the term emerged from business management (and finance to a degree) and have been formalized in that domain over the years. For us software types, we have various books describing design patterns and such. We all have experience and opinions about those. Whether any of them are “best” in any context is a matter of opinion/debate.
My sincere hope is that the session presents the practices that SAG/IBM has seen work in the past along with the as-specific-as-possible contexts. “Best” becomes a distraction and risks blind adoption without considering whether or not the practice works in their specific situation.
But there can be best practices, like dependency injection, or proper indentation in the code or using functions or OOP rather than copying the code block, or defining a constant variable instead of using the constant directly as a number. These are all best practices. Imo the problem rises when we use best practice for everything. Its like, using !important in CSS. If you do it once or twice, it is ok. But if you write it everywhere, then you have an antipattern. Its still better not to use it at all, may be.
The premise of the article I shared, and my own opinion, is there are not. I will certainly support that dependency injection, “proper” code indenting, modularization, etc are commonly used and would advocate for them in the right contexts. But I would never presume that any of them are best in a given situation. Side trip: if there is a desire to do so, can certainly explore the “-ilities” of DI or other techniques mentioned. Here is a blog that talks about DI and DI frameworks and tradeoffs.
This Forbes article offers additional rationale for avoiding the phrase, and is a bit less confrontational than the first article. It offers a thought much like your statement “the problem rises when we use best practice for everything.”
I’m not recommending a blatant disregard for existing methodologies, but rather a very critical eye as to whether or not they are appropriate beyond the fact they’re already in use.
Thus, my somewhat Quixotic quest to eliminate a term that in my view adds no value and indeed can be harmful.
I failed to elaborate on this item. In these books the authors describe the contexts and scenarios, along with the pros and cons, where the patterns can be reasonably applied. In general, they don’t use the term “best practice” for any of them. No need to do so. These are the things to focus upon, not some vague notion of “best.”
There are many practices/implementations that multiple groups have used successfully in various situations. That does not make them “best.” Just possibly common.