How amusing that the very topics I had planned for my blog became a topic of discussion before I could even write up my post. I was planning to list some best practices in my field of work since quite sometime now, as I'm a believer in the concept due to the goal it intends to achieve—better and efficient performance. Looking at the posts and comments on Jane Bozarth and Tony Karrer's blogs it appears that the term is either 'overused' or misunderstood. I never had any doubts about what it meant until I read these posts. I read Jane Bozarth's post on The Myth of "Best Practices" the day she posted it and empathized with her point of view that people expect to get best practices for almost anything they want to learn. She's right from her perspective in saying that before asking such questions, one needs to understand that...
------------------------------------------------------------------------------------------------
A "best practice" is best only in the precise, specific context in which it exists.
------------------------------------------------------------------------------------------------
Today, Tony's post on Sharing Best Practices—Patterns originated from the same source, but I thought succeeded in dissecting the context and origin of term best practice and arrived at design patterns very beautifully. This is the way I would like to understand the concept of best practices too and totally agree with Tony. Thus, though I had absolutely no plans of writing a post on best practices, here I am writing one! After reading all the discussions, I now have formed an opinion that I want to share. Not intending to digress though, I think it is worth mentioning that today I read another post by Tony on New Blogs and how new bloggers have trouble thinking of topics to write. It seems that reading other bloggers posts intently can also give you wonderful ideas on what to write on your blog.
Getting back to the topic under discussion, best practices and patterns, I suggest fully reading Jane and Tony's posts and the comments, before reading mine. In this post, I plan to illustrate the points raised in the discussions with real-life scenarios, which is my favorite way of making people delve deeper into a topic. Once you have context, you begin to see the value of things which otherwise seem meaningless or irrelevant. I urge each of you to think about the scenarios that you find relevant with this post and share your thoughts.
Scenario 1:
As instructional designer, I use a course outline and a storyboard template in order to eliminate the redundant task of thinking what all I need to cover in a course outline, and what all I need to write in a storyboard. Now this is a best practice we follow to help us work efficiently and focus on the main goal we're trying to achieve here—Build a Course!
It is worth noting here, as to how the template was created; by observing a pattern of information that all courses largely require!
The same example applies when I build a custom course template with a menu, previous, and next buttons. Even Rapid elearning tools are built on the concept of observed patterns in elearning courses. Using the custom or rapid elearning tool can be interpreted as a best practice in order to avoid unnecessary errors and stay focused on the goal—Building a Course!
Scenario 2:
I've just decided to update my Nokia handsets firmware as I discovered there is an update to it. I browse to their website where they have beautifully documented the procedure on how to update my Nokia phone's firmware. If you look at the pre-installation task list (Points to note), you will note that they are essentially best practices. You will also find FAQ that give you questions of exactly what may happen during your phone upgrade and under what circumstances you should or should not panic. The FAQ are designed based on observed patterns and help make the update process predictable for a first timer.
The same can apply when you use any tool for the first time. Think about this; what if Nokia just gave you the software to download but never gave you the pre-installation steps and FAQ? What could happen? Your opinions are welcome...
Scenario 3:
I did save the best one for the last and hope this one illustrates the dicussion well. Let's say your organization has a retail product (consisting of ordering, billing and inventory) that they sold to a premium retail store. The product implementation is complex and cannot be installed and configured by just running a single setup.exe file. In order to get your product installed in the customer's enterprise, the customer needs to do many tasks:
- Plan the entire installation—how many machines needed, what applications to install on each machine, and how to evenly distribute the load so that the system performs optimally.
- Setup and configure several machines/servers for the database and application servers.
- Install and configure the database and application servers respectively on each machine.
- Install and configure each product.
- Connect and integrate the products so they can communicate, meaning:
- Ordering takes the order after checking with inventory.
- Then confirms the order and sends the information to billing.
You need to imagine a process running in the midst of all these applications and giving directions on what to do and when. By now you should understand that these are common but complex setups for an enterprise and involve a lot of risk.
This, I believe, is a strong case requiring one to have best practices and available design patterns to implement a complete product solution. If the planning or the implementation of this kind of a system goes wrong, it could lead to disastrous results like:
- degraded system performance;
- system malfunction leading to loss of valuable business information;
- unexpected system behavior.
The result: A major loss in the business.
The way to avoid such events from occurring, would be to follow certain best practices, as the problems listed above are actually common failure patterns observed in such systems. The way to prevent this problem would be to:
- Create backup servers to backup data regularly.
- Use advanced features like clustering to distribute the load on different servers (if your order volumes are high)
- Go with recommended patterns for designing and integrating such systems.
Finally, I'd like to conclude this discussion by reiterating some points:
- Best practices can be arrived at only from experience and real time implementation of a process or product, and are always specific to the domain of expertise. Thus, I agree with the comment that called them 'expert practices'.
- Using proven patterns as a base saves us from running into problems that others have already run into, and also prevent us from reinventing the wheel and wasting effort. It pays to work smart by leveraging on and building upon existing information or proven patterns to fit our need; just like I just did with Tony's post. I just used the theoretical knowledge he gave on his post and illustrated them with real-life examples. :)
So irrespective of the name we'd like to give them, we do need 'things' of the nature of best practices and patterns to help us do our job better.
I would like to hear from all of you as to what you think here...
------------------------------------------------------------------------------------------------
A "best practice" is best only in the precise, specific context in which it exists.
------------------------------------------------------------------------------------------------
Today, Tony's post on Sharing Best Practices—Patterns originated from the same source, but I thought succeeded in dissecting the context and origin of term best practice and arrived at design patterns very beautifully. This is the way I would like to understand the concept of best practices too and totally agree with Tony. Thus, though I had absolutely no plans of writing a post on best practices, here I am writing one! After reading all the discussions, I now have formed an opinion that I want to share. Not intending to digress though, I think it is worth mentioning that today I read another post by Tony on New Blogs and how new bloggers have trouble thinking of topics to write. It seems that reading other bloggers posts intently can also give you wonderful ideas on what to write on your blog.
Getting back to the topic under discussion, best practices and patterns, I suggest fully reading Jane and Tony's posts and the comments, before reading mine. In this post, I plan to illustrate the points raised in the discussions with real-life scenarios, which is my favorite way of making people delve deeper into a topic. Once you have context, you begin to see the value of things which otherwise seem meaningless or irrelevant. I urge each of you to think about the scenarios that you find relevant with this post and share your thoughts.
Scenario 1:
As instructional designer, I use a course outline and a storyboard template in order to eliminate the redundant task of thinking what all I need to cover in a course outline, and what all I need to write in a storyboard. Now this is a best practice we follow to help us work efficiently and focus on the main goal we're trying to achieve here—Build a Course!
It is worth noting here, as to how the template was created; by observing a pattern of information that all courses largely require!
The same example applies when I build a custom course template with a menu, previous, and next buttons. Even Rapid elearning tools are built on the concept of observed patterns in elearning courses. Using the custom or rapid elearning tool can be interpreted as a best practice in order to avoid unnecessary errors and stay focused on the goal—Building a Course!
Scenario 2:
I've just decided to update my Nokia handsets firmware as I discovered there is an update to it. I browse to their website where they have beautifully documented the procedure on how to update my Nokia phone's firmware. If you look at the pre-installation task list (Points to note), you will note that they are essentially best practices. You will also find FAQ that give you questions of exactly what may happen during your phone upgrade and under what circumstances you should or should not panic. The FAQ are designed based on observed patterns and help make the update process predictable for a first timer.
The same can apply when you use any tool for the first time. Think about this; what if Nokia just gave you the software to download but never gave you the pre-installation steps and FAQ? What could happen? Your opinions are welcome...
Scenario 3:
I did save the best one for the last and hope this one illustrates the dicussion well. Let's say your organization has a retail product (consisting of ordering, billing and inventory) that they sold to a premium retail store. The product implementation is complex and cannot be installed and configured by just running a single setup.exe file. In order to get your product installed in the customer's enterprise, the customer needs to do many tasks:
- Plan the entire installation—how many machines needed, what applications to install on each machine, and how to evenly distribute the load so that the system performs optimally.
- Setup and configure several machines/servers for the database and application servers.
- Install and configure the database and application servers respectively on each machine.
- Install and configure each product.
- Connect and integrate the products so they can communicate, meaning:
- Ordering takes the order after checking with inventory.
- Then confirms the order and sends the information to billing.
You need to imagine a process running in the midst of all these applications and giving directions on what to do and when. By now you should understand that these are common but complex setups for an enterprise and involve a lot of risk.
This, I believe, is a strong case requiring one to have best practices and available design patterns to implement a complete product solution. If the planning or the implementation of this kind of a system goes wrong, it could lead to disastrous results like:
- degraded system performance;
- system malfunction leading to loss of valuable business information;
- unexpected system behavior.
The result: A major loss in the business.
The way to avoid such events from occurring, would be to follow certain best practices, as the problems listed above are actually common failure patterns observed in such systems. The way to prevent this problem would be to:
- Create backup servers to backup data regularly.
- Use advanced features like clustering to distribute the load on different servers (if your order volumes are high)
- Go with recommended patterns for designing and integrating such systems.
Finally, I'd like to conclude this discussion by reiterating some points:
- Best practices can be arrived at only from experience and real time implementation of a process or product, and are always specific to the domain of expertise. Thus, I agree with the comment that called them 'expert practices'.
- Using proven patterns as a base saves us from running into problems that others have already run into, and also prevent us from reinventing the wheel and wasting effort. It pays to work smart by leveraging on and building upon existing information or proven patterns to fit our need; just like I just did with Tony's post. I just used the theoretical knowledge he gave on his post and illustrated them with real-life examples. :)
So irrespective of the name we'd like to give them, we do need 'things' of the nature of best practices and patterns to help us do our job better.
I would like to hear from all of you as to what you think here...
A commenter on my blog post, someone I know only as "Joanna" offered an interesting idea: the concept not of "best" practices (they are already outdated and those who once used it have moved on) but of "next practices". Here is her whole post:
ReplyDelete"I was listening to a Finnish future researcher Jari Koskinen (Finland Futures Research Centre at the Turku School of Economics) at the end of last year in a conference, and he gave an interesting viewpoint for the 'best practices' issue. In his opinion, best practices represent something quite static and already outdated. When the rest are applying the best practices (something that the forerunners have invented a while ago), at that point of time the forerunners are already far away, looking to the future :)"
For more on this I heartily recommend Atul Gawarde's "Better" for its section on "best practices" work on treatment for cystic fibrosis.
Yep rightly said, the "best practices" are nothing but "expert practices" cataloged based on "years and years of domain expertise". Mainly followed to do things with "consistency" and "to leverage on the proven patterns to focus and spend time on achieving the business goals".
ReplyDeleteThe challenging part in this area is - how we expand our design patterns in order to expand our catalog of best practices. If every body is spoonfed with a list of best practices, the list will become stagnant after a while if they just use it as a base for their work. Its important for everybody to use their expertise in that area and play with (randomize) the patterns to arrive at new patterns which might become best practices at a later point of time.
@Jane, thanks for sharing this view. I have been thinking about the concept of next over best ever since you posted it here. I will certainly write something once i have a convincing point or a clearer idea of this. My only point was to highlight that you do need best practices and even come up with the next. If is did not experience something in the past I cannot create something for the future. So in my domain, I find that best practices would prove useful to even creating next practices, as product architectures don't change with every release. You merely add new features, improve performance and usability over time. So knowledge of how the product was designed in the past becomes a forerunner to making improvements in future, based on currently applicable standards.
ReplyDelete@LSP, thanks for your view point. I think the answer to your point is to evolve better designs while keeping in mind lessons learned from past implementations, unless something becomes obsolete or unless you redesign your product, where in this design pattern of a successful implementation would be forced to change. The idea after is to minimize the risk of real time implementations.