Overview and Mission
From ServoyFORGE Wiki
Best Practices, across all industries and personal pursuits, can be described as: "Processes and activities that have been shown in practice to be the most effective." [1]
By definition, then, Best Practices are not laws but rather recommended approaches, based on real-world experience, to achieving successful results. And, just as different people might take different approaches to a mathematics problem yet both arrive at the same (successful) answer, within the world of software development one developer's preferred approach is likely to differ from another's. And, indeed, even the meaning of the word "success" is quite subjective. For example, for two projects -- one that needs to be rolled out as quickly as possible, and another that will become a vertical market solution -- developers might apply distinct sets of Best Practices ... and both approaches could be perfectly valid for the particular circumstances.
With all of this in mind, then, the only way for a community of developers to collectively document "Best Practices" is to set out agreeing to disagree on some points, and for readers of such documented practices to be prepared to read several alternative views, and in the end to decide upon an approach that is best for a given team, solution, or environment. This Servoy Best Practices wiki was launched not in an attempt to establish Absolute Truth but in the belief that the Best Practices that may evolve on these pages will serve as a incubator for further inquiry and refinement of the "recommended approaches" that are posted here.
BEST PRACTICES POSTING NOTES:
1. Please read the definition at the very beginning of this page. Best Practices are not theories, they are conclusions drawn from real experience: '"shown in practice to be the most effective." Do not post pure theory here; please do post practices you or others have evolved via hands-on testing and empirical analysis.
2. We will all rely on others to question our own articles and edits, so be prepared to challenge and be challenged. We will act like professionals when we offer any critique on Discussion pages, and we will also all be prepared to accept critique.
3. It may come to pass -- in fact it is probable! -- that two or more strongly reasoned but different approaches to a particular aspect of Best Practices will arise during discussions. (One likely example of this is naming conventions.) When this occurs, alternative approaches will be split into separate articles, so that editors who ascribe to the different approaches will not find themselves in an "editing battle". With a separate page for each approach, Best Practices wiki participants with differing ideas can continue to refine and edit the article covering their own adopted practice without interference.
4. If you write up or quote a Practice that you have read elsewhere, be sure to obtain the original author's permission and to properly attribute -- and link to where applicable -- the source.
Notes
- ↑ California State University "Data Warehouse" Glossary page: http://it.csumb.edu/departments/data/glossary.html)