There is a brilliant online piece on learning titled Patterns of Learning that uses chess to explain how we use patterns to learn. It shows how individuals first learn the parameters of the chess board, the names of the pieces, etc. The piece shows how only a prolonged study of notable patterns and the ability to reproduce them without much effort can make one a chess master.
Chess is different from computing in that patterns derived from games played hundreds of years ago are still relevant today. Computing patterns come and go much more quickly. Patterns emerge in far smaller cycles and die out. If we are to keep pace we must be able to identify, absorb, and appropriately retire patterns consciously.
Bad Uses of Patterns
There are several particularly bad uses for patterns.
- First involves following them dogmatically. Everything is ultimately subject to change as people learn new things. That means patterns should be flexible.
- The second bad use of patterns involves ignorance of patterns themselves. When we refuse to recognize that we are actually using patterns they develop organically. This means some patterns are built upon other ad-hoc patterns forming a weak foundation. The result? At some point the entire structure collapses.
- Third, when patterns become unnecessarily complex they lose value. We must continuously guard against patterns becoming unnecessarily complex.
No discussion of patterns would be complete without briefly touching upon the venerable anti-pattern. Anti-patterns tell you what to watch out for. A good anti-pattern would be to not build bridges out of matchsticks. An anti-pattern for LIMS might be to avoid building the entire system in Microsoft Word.
The DIY LIMS Pattern
The DIY LIMS pattern can be summarized like this: Laboratory information management systems can be constructed from independently produced components much the same way that a computer can be constructed from store-bought parts. Several things are needed to make this a practical reality:
- Developers of open source LIMS need to entertain the core concept of DIY LIMS -- that is, systems should be built using a component-based architecture with components that interoperate. Like in a computing architecture, the components need not come from the same source.
- The communication between those components needs to be well defined.
- Interoperability and construction in this fashion should not destroy performance. Modular parts should be able to perform reasonably well.
- Patterns used in development must be explicitly described to reduce the problems of redundancy. For instance, if Module A is an SQC module and Module B performs a similar function but in a different way the differences therein need to be explicitly described, not hidden in the code.
There was a time when people actually believed that the world was flat. After some experimentation, however, that proved to be false. The idea that DIY LIMS cannot succeed may hopefully one day be cataloged alongside this in the great encyclopedia of human misconceptions. Until then we need the courageous to investigate, develop, discuss, and work toward the common goal.
Citation: Developing with Patterns. (2014). Retrieved Sun Apr 30 04:57:52 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1392373645