The Context is What Matters
Lately, I have been in many discussions regarding best practices and patterns. The discussions started out with an attempt at defining “what is a ‘best practice‘?“. While speaking about the relevance of a “best practice”, I saw this blog entry from Ted Neward which asserted there is no such thing as a best practice. After much debate, I agree with this assessment. Without a context there seems to be no “best practice“. When there is a context there are usually multiple practices which can bring successful results in that context.
From this, we started to have discussions on whether a “best practice“ can be defined as a pattern to achieve success within a context. If an organization defines “best practices“ which are to be used within their designated contexts would this enable higher business success? I believe that the first paragraph somewhat answers this question. If there are two contexts which look similar in nature, is it always correct to use the same “best practice“? Since there may be many practices which will succeed within the defined contexts similarities, would it not be more agile to choose the practice which is better suited at that point in time?
During one of my conversations with a colleague, I remembered some of the thoughts that I had a couple of years ago regarding design patterns. Design patterns are defined in terms of a context and can be implemented in multiple ways depending upon the circumstances of the context. In order to use design patterns in software, a developer must either have access to a library of design patterns or they are using them from experience with the context. In either case, experience is a required attribute of the developer. In the case of a design patterns library, I believe that the lack of success for CASE tools has shown weaknesses in the ability to gather design patterns into a valuable library. With many companies hiring developers with less experience, the use of design pattern libraries becomes a detriment rather than an asset. These developers are more worried about syntax, data structures, and learning APIs than whether to use a “composite“ or “decorator” design pattern.
This all leads me back to the experienced developer who has worked within the context before and has found viable solutions for it. What is the important part of this equation in creating or finding solutions? I believe it to be the context itself. If we can define a library of contexts within a domain, such as software development or requirements gathering, we may then gather contributions from our teams into a useful knowledge management system. Without the contexts, it will be near impossible to find practices which are helpful to those looking for practices to use in their current contexts. Also, the library of contexts should be continually refactored by the teams in order to keep them current.
All of this could have been somewhat derived from Ted‘s original blog entry and probably is within some knowledge management theory paper somewhere. Books and magazines have been an outlet, as well, for the definition of contexts in some respects but I believe that most are not focused enough to define real world contexts. I think this topic is important to solve as we move towards real-time competitive markets and our IT infrastructure is further challenged with providing the competitive edge.
